All articles
61 articles
-
Rate limiting — how to test the limits everyone remembers only after an incident
While nobody is hammering the API, limits seem unnecessary — their absence is invisible right up until the first incident. A first-person take: the limit as a two-sided contract (the server restricts — the client survives it), the N/N+1 boundary and an honest 429 with Retry-After, key scope and how an account-based limit lets attackers DoS a victim, the burst at window boundaries, bypasses via X-Forwarded-For and sibling endpoints, the zones where a limit is mandatory (OTP, reset, promo codes), and why 'limits are off on staging' equals an untested production.
-
A QA's first 30 days on a new project — how to ramp up without doing anything dumb
Day one: unfamiliar product, confusing environments, and someone's already asking you to 'take a quick look at this feature.' A first-person take: fresh eyes as a resource with an expiration date, a week spent as a user, a risk map built from three questions to the team ('what breaks most often? what was the last incident? where are you afraid to touch?'), exemplary first bug reports, why criticizing processes in week two is the worst move, small finished improvements by the end of the month, and a 30-day checklist.
-
Autotests that aren't in CI are a hobby: wiring tests into the pipeline without drowning
400 autotests that run "sometimes, locally" are not automation. A first-person take: run layers (a PR gate budgeted in minutes / post-merge / nightly), sharding and why parallelism kills dependent tests, a retry policy that doesn't mask flakiness (passed-on-retry = yellow, not green), quarantine with exactly two exits, the red-main rule, failure artifacts (a trace instead of re-debugging), and suite health metrics.
-
Registration & login testing checklist — with a Playwright autotest for every item
Login is the first screen a user sees and a favorite spot for production incidents. The "checklist item → how to automate it" format: user enumeration via identical error messages, password reset with a single-use token, logout and the back button, HttpOnly/Secure cookies via context.cookies(), sessions across two tabs, mocking 429 for lockout UI, the storageState pattern so you don't log in inside every test — and what parts of auth should never go into e2e.
-
Update testing — the bugs only users on old versions ever see
The release was tested perfectly — on a clean install. But almost every user gets it as an update on top of an old version with old data. A first-person take: why an update means new code reading old data, the N-5 → N version matrix and migration chains, updates landing mid-session, force update and its bypasses, staged rollout and a server that must support two versions at once, downgrade as a crash loop, first launch after an update ≠ FTUE — and why an archive of old builds must exist.
-
"It shows me old data" — how to test caches, the quietest source of bugs
The "user sees stale data" bug doesn't reproduce, gets closed as "went away on its own" — and comes back a week later. That's not mysticism, that's a cache. A first-person take: the map of six caching layers (browser, CDN, gateway, application, database, mobile client), invalidation as the main test case, caches leaking other users' data, cache stampede after a deploy, the "every case twice — cold and warm" rule, and why testing with the cache off means testing a system that doesn't exist.
-
"How long will testing take?" — giving estimates without digging your own grave
You blurt out "two days" in three seconds, and that number then lives for weeks — and gets used against you. A first-person take: why test estimation is a special genre (you're estimating the quality of someone else's work that doesn't exist yet), an estimate as a forecast with assumptions, decomposition instead of a single number, three points instead of one, a named buffer instead of "×2 just in case", and what to say when your time gets cut.
-
What to automate and what to leave manual — and why 'automate everything' kills the suite
'Automate everything' turns into a red suite nobody trusts within six months. A first-person take: the test we fixed for half a year when we should have deleted it; why an autotest costs not 'to write' but 'to maintain for years'; what's worth automating (stable, frequent, expensive by hand, deterministic) and what to leave to a human; the pyramid as a decision calculator; why a flaky test is worse than a missing one, plus an 'automate or not' checklist.
-
Screen states: empty, loading, error — and the ones people forget until a bug arrives
Screens get designed for the happy path, but the user sees loading, emptiness or an error first. A first-person walkthrough: the empty screen that looks like a stuck loader; why 'nothing here yet' and 'nothing found' are different empties; why an error must not look like emptiness; offline, partial load, stale data, errors on load-more; accessibility of empty and error states, plus a compact checklist.
-
Crashes and ANRs in a mobile game: catching what won't reproduce for you
Crashes almost never happen on your device — they live on other people's, where memory is tight and the network drops. A first-person walkthrough: why you should test the crash reporter itself first (a real case where Crashlytics initialized after the crash and the exception handler was grabbed by the ad SDK), how a crash differs from an ANR, why you need symbolication and context in the report, managed vs native crashes in Unity, and how to deliberately recreate other people's conditions.
-
Chaos Engineering for QA: deliberately breaking the system to test resilience
Resilience you never tested with a deliberate failure is an assumption, not a fact. Chaos Engineering for QA: the steady-state hypothesis, blast radius and the abort button, what failures to inject (instance kill, latency, dependency outage, resource exhaustion, zone outage), tools (Chaos Monkey, Gremlin, Chaos Mesh, AWS FIS, Toxiproxy), Game Days, the QA role (graceful degradation, retries, circuit breakers, observability) and a safe-experiment checklist.
-
How QA and developers can stop fighting: reporting bugs and giving feedback without conflict
QA–developer conflict is almost never about the bug — it's about how it's communicated. How to report bugs and give feedback without friction: the bug is about the product, not the person; a report structure that defuses defensiveness; feedback language (SBI and Lara Hogan's formula); severity without drama; handling 'works as designed'; shift-left; when to escalate; blameless culture and a 10-point checklist.
-
Search and filters testing checklist — and how to automate every item with Playwright
Search and filters are almost everywhere, and the bugs are always the same. A checklist of what to test (edge-case queries, debounce, request races, empty state, XSS, filters in the URL, resilience to backend errors, localization) — and for each item a real Playwright test via network interception with page.route. Plus what NOT to automate in e2e.
-
Testing runtime permissions in a mobile app: states, on-the-fly revocation, and edge cases
Permissions aren't 'granted or not' — they're a state matrix. A five-state model, pre-permission priming, graceful fallback on denial, process death on on-the-fly revocation, background and precise/approximate location, ATT and limited Photos on iOS, 'Don't ask again' on Android, verifying via Proxyman traffic, and a 12-point checklist.
-
Observability for QA: logs, metrics, traces — what to test and how to use it
Observability through a tester's eyes: the three pillars (logs/metrics/traces) in plain language, how to test observability itself (trace id, metrics, secrets in logs), how QA uses it to localize distributed bugs and silent degradations, SLI/SLO/error budget, and an observability-ready feature checklist.
-
Burnout in QA: early signs, causes and how to pull yourself (and the team) out
Burnout in testers: how it differs from tiredness (the 3 WHO dimensions), why QA is at risk, the early signs, three levels of causes (personal/team/process), what actually helps, what a team lead should do, and a self-check mini-checklist.
-
AI bots that play your game: game-QA automation in 2026
AI agents for game testing: how they differ from scripted automation, what they actually do (24/7 exploratory play, crashes, balance, video logs), the limits and risks, who's on the market (modl.ai, AltTester, GameDriver), when to use AI bots and when plain automation is enough. A pilot checklist.
-
File upload testing checklist: 30+ cases people forget
A reusable file upload testing checklist: content vs extension and magic bytes, sizes and decompression bombs, file names and path traversal, the upload process and dropped connections, server-side processing and storage, security (SVG XSS, RCE, SSRF) and accessibility. 30+ points.
-
FTUE / onboarding in a mobile game: what to test in the first session
The first session (FTUE) through a QA lens: the matrix of entry points (install/reinstall/deep link/login), tutorial interruptions, skip and mandatory steps, returning player and updates, idempotent reward, A/B and funnel analytics. A 12-point checklist.
-
Testing deep links: deep links, Universal Links, App Links and the state matrix
Deep links through a QA lens: three link types, the state matrix (foreground/background/killed/not installed), deferred deep linking and attribution, fallbacks and broken links, security, AASA/assetlinks verification, tools adb/simctl/Proxyman. A 12-point checklist.
-
Mock servers for QA: WireMock and friends — when to replace a dependency with a stub
When an external dependency can't or shouldn't be run for real, you mock it. Why mock, what a good mock server does (stubs, fault injection, record/replay, verify), tools WireMock/MockServer/Mockoon/Prism/Hoverfly, mock vs Testcontainers, contract drift and Pact. A 10-point checklist.
-
Load testing: how to design it and not get garbage numbers
How to do load tests right: types (load/stress/soak/spike/breakpoint), percentiles instead of the average, open vs closed model, realistic data and traffic profile, server-side metrics and saturation, coordinated omission, tools k6/Gatling/Locust/JMeter. A 12-point checklist.
-
QA interview in 2026: how to prepare and what's actually asked
A prep map for the QA interview: theory and test-design techniques, severity vs priority, a framework for answering 'test X', bug reports, the API/SQL minimum, automation, behavioral questions via STAR, and company red flags. A 10-point checklist.
-
Test data in automated tests: a source of flakiness and coupling — and how to prepare it
Test data is one of the most invisible sources of flaky tests, bigger than locators. Isolation, determinism (freeze clock, seeded Faker), uniqueness under parallelism, factories vs fixtures vs API setup, cleanup and anonymizing prod data. A 12-point checklist.
-
Form testing checklist: 30+ cases people forget
A reusable form testing checklist: text fields and trimming, validation, numbers and money, email/phone/date/password, masks and autofill, double submit and idempotency, network, security and error accessibility. 30 points + a mini template.
-
Testing ads in a mobile game: rewarded, interstitial, mediation and edge cases
Ad monetization through a QA lens: how to test rewarded and interstitial ads, reward idempotency (SSV), no-fill, mediation and waterfall, frequency capping, ATT/GDPR consent, network and analytics. A 13-point checklist.
-
Testcontainers: real databases, Kafka and Redis in tests instead of mocks and a shared environment
How to test integration against a real Postgres, Kafka and Redis in Docker — without lying mocks or a flaky shared environment. Wait strategies, reusable containers, Ryuk, modules, CI, and a 10-point adoption checklist.
-
Knight Capital: how $440M vanished in 45 minutes because of one deploy
A QA-eye breakdown of the August 1, 2012 disaster: a reused feature flag, an unnoticed 8th server, the dead Power Peg code, and 97 ignored alerts. 7 lessons and a 10-point release-process checklist.
-
Idempotency and retry storms — what QA must test in distributed systems
The most expensive class of bugs in payments isn't 'didn't go through' — it's 'went through twice'. A QA-eye view of idempotency: Idempotency-Key, 5 typical retry scenarios, retry storms, tools (WireMock, Toxiproxy, k6), and a 13-point release checklist.
-
1-1s for QA — what to prepare, templates, and how to talk about growth with your lead
A 1-1 is a tool for your growth, not a status report. 90% of QAs burn 50 meetings a year. 5 types of content, ready scripts for 5 painful topics (promotion, burnout, conflict), a 1-1 doc template, and a pre-meeting checklist.
-
Android fragmentation for a mobile game — what MIUI, One UI, EMUI, and Oppo/Vivo battery savers break
«Works on Pixel, crashes on Xiaomi, different bugs on Samsung, no Google Play on Huawei.» Complete 2026 fragmentation guide: 6 OEMs with their quirks, what breaks in games, the minimum QA lab, a checklist, and bug-report format.
-
Claude in QA is overrated — 10 scenarios where it falls short, and where it actually pays off
The QA community has hyped «Claude will replace manual QA». In production those promises don't hold up. A contrarian breakdown without anti-AI rhetoric: 10 overrated scenarios, 5 systemic limits, hidden risks, and 5 places where it actually works.
-
CrowdStrike, July 2024 — how a single driver bricked 8.5 million Windows machines in 78 minutes
The most expensive software failure in history — $5.4B in direct losses. A trivial off-by-one on the side of an internal validator. Full timeline, root cause, three separate QA failures, and 10 lessons for your team.
-
OWASP API Security Top 10 for QA — a guide with test cases
Most QAs know SQL injection and XSS. But 90% of vulnerabilities in modern products live in APIs, and the OWASP API Top 10 2023 is a separate list that QA courses don't cover. All 10 threats with test cases, curl snippets, and tools.
-
Bad news to stakeholders — how QA should communicate release problems
The soft skill that separates junior from senior. Most QAs either drag it out or dump panic. 11 sections: principles, ready templates for 5 typical situations, channels, escalation, postmortem.
-
AI and auto-healing locators in autotests — what actually works in 2026
The most expensive part of a mature autotest suite is locator maintenance. A whole class of products was built around that pain under the «AI-powered» label. 8 sections: what's under the hood, Healenium vs Mabl/testRigor/Functionize, where LLMs actually work, risks, and a rollout plan.
-
Accessibility checklist for a mobile app in 2026
On 28 June 2025 the EU's European Accessibility Act came into force — for b2c apps a11y is now a legal requirement. 11 sections of a QA checklist: VoiceOver/TalkBack, Dynamic Type, contrast, touch targets, semantics, automation.
-
Cloud Save in a mobile game — a testing checklist
A player finished 30 levels on iPad, opens iPhone — progress is gone. The most reputation-expensive part of a mobile game. 9 sections and a QA checklist for cloud save: APIs, conflicts, cross-platform, corruption, recovery.
-
API tools for QA in 2026 — Postman, Bruno, Insomnia, Hurl: which to pick when
A comparison of four API tools on the dimensions that matter in real QA work. Postman pushed into the cloud, Bruno grew up as a git-friendly alternative, Hurl owns the CI niche.
-
Testing on a bad network — 8 scenarios and tools
Most QA checklists cover only «internet works» and «Airplane mode». Real users live between those. 8 network-degradation scenarios with tools and acceptance tests.
-
5 testing types that cover 90% of real work
There are dozens of testing types in theory. In practice, five of them fill 90% of your day. Where each applies, what it catches, where it fails, and the most common mistakes.
-
Junior → Middle → Senior QA: real growth signals at each level
Half of QA engineers get stuck between levels for 1–2 years. Not because they lack knowledge — but because they don't understand what's expected on the next rung. A level-by-level breakdown: what's expected, what isn't, readiness signals, anti-patterns, a self-assessment checklist.
-
Classical QA is dying. What replaces it
The classical QA approach was built on a simple idea — if we test thoroughly before release, we can trust the system after release. Today that no longer works. Here's what needs to change.
-
Visual Regression testing: a complete guide
Functional test is green, button clicks, form submits — and the user looks at the screen and sees the icon shifted 4 pixels left and overlapping the text. Visual regression closes that gap.
-
Claude for QA engineers: 10 real scenarios and prompts
AI assistants have moved from 'novelty' to legitimate working tool. For QA, this is especially powerful — routine tasks like test-case generation, log triage, prompt-shaped data.
-
Push notifications: a 10-section testing checklist
Push notifications are one of the most under-tested features in mobile apps. A QA checklist usually says 'arrived / not arrived'. But there are dozens of real cases hiding behind it.
-
Testing In-App Purchases in a mobile game: 9 sections and a checklist
IAP is the most expensive code segment for a bug. One missed case of 'money charged, item not granted' means support tickets, refunds, bad reviews, and retention at risk.
-
Maestro vs Appium: what to choose for mobile UI testing in 2026
Appium has held the throne since 2014, but if you're picking a stack for mobile UI tests today — look at Maestro. Faster to install, simpler to write, and for casual projects often covers 100% of needs.
-
Proxyman for QA: guide to inspecting and rewriting HTTP traffic
HTTP/HTTPS traffic between an app and a server is the single biggest source of mobile bugs that are hard to reproduce: analytics, IAP, ads, remote config, A/B tests, push notifications.
-
Mars Climate Orbiter: $327 million lost over pounds vs newtons
September 23, 1999: NASA lost a spacecraft approaching Mars. No hardware failure, no communication issue. It was a benchmark bug in integration testing.
-
Performance testing for a mobile game: 7 metrics that actually matter
'The game lags' is too abstract for a ticket. To make a performance problem reproducible, measurable and trackable — you need concrete numbers. Here are 7 metrics worth checking every release.
-
Playwright auto-wait: why you don't need explicit waits
If you came to Playwright from Selenium — your first instinct is to write waitForSelector before every action. 90% of the time it's redundant work: Playwright already waits for you.
-
Localization checklist: 10 traps you catch in a single pass
Localization is not 'run the strings through a translator'. With 5+ languages, a dozen bug classes appear that are invisible in English. A compact checklist covering 90% of real problems.
-
What the emulator won't show: 5 classes of bugs found only on real hardware
Emulators speed up CI and are convenient for smoke tests, but relying on them alone is self-deception. Some problems only appear on a real device with a real load, battery and sensors.
-
The test pyramid is outdated: what big teams use instead
Mike Cohn's classic pyramid (2009): lots of unit, medium integration, few E2E. The model was born when UI frameworks were heavy. Now Playwright and Cypress run in seconds — what teams use instead.
-
Checklist for testing date and time fields
A 'pick a date' field looks innocent — but date/time fields fail more tests in production than anything else. Time zones, DST transitions, locales, leap years — every item has shot someone.
-
Why your Selenium tests fail intermittently: 5 reasons for flaky tests
Flaky tests are the biggest source of distrust in automation. Per the Google Testing Blog, about 1.5% of all green CI runs contained at least one flaky failure. Usually the problem is in the test, not the product.
-
Playwright: where to start and how to learn
Playwright became the web automation standard in 2023-2025. A curated set of resources to help you switch from Selenium/Cypress or start from scratch.
-
adb for mobile QA: 40 commands that save hours
ADB (Android Debug Bridge) is the main tool for mobile QA on Android. A list of commands that are actually used during regression and bug triage.
-
5 books every tester should read
QA as a profession has classic literature — every senior engineer knows it. If you haven't read them, time to fix the gap. 5 books that shaped the modern approach to testing.
-
English for QA: free resources that actually help
A QA engineer without English is a career constraint. Docs, the best books, conference talks, communicating with the team abroad — it's all in English. A collection of free resources people actually use.