qa
52 articles
-
Phantom Users: Where the 'Bots' in Your Mobile Analytics Come From and How to Tell Them from Fraud
A batch of new users suddenly shows up in your analytics, all on the same old phone model: they open the app, poke around for a minute and leave. The first thought is fraud and a burned ad budget. Often it's Google's own robots from the pre-launch report. How to tell test devices from bots, check the source in five minutes, and filter that traffic out so it doesn't ruin your funnel and retention.
-
Memory Leaks: How to Catch the Bug That Only Shows Up After an Hour
The app works perfectly for five minutes and crashes after an hour. A classic memory leak that no short test case catches. We cover what a leak looks like from the QA side, which scenarios expose it, how to measure memory on Android, iOS, Unity and the web, and what to attach to a bug report so a developer finds the cause in an hour, not a week. With a checklist.
-
The Right to Say No to a Release: When QA Blocks a Launch and How to Do It Without a War
Friday evening, release in an hour, and you have a bug in hand. Block it or stay quiet? We cover why QA is not a gatekeeper but not a bystander either, when a 'no' is justified, how to phrase it, the options between 'yes' and 'no', and what to do when the release ships against your recommendation. With a checklist.
-
Remote Config: How to Test What Changes Without a Release
A Remote Config hotfix didn't apply because an old cached config overrode the new one, and the 'fix' was verified on a build players don't have. A first-person breakdown: config versions, when changes actually reach the player, compatibility with old clients, and a QA checklist.
-
Game Balance Breaks Through Numbers, Not Bugs: Catching Exploits with a Simulator
A tester beat my idle game to wave 199 in one evening, even though everything 'worked'. A first-person breakdown: why balance can't be tested by hand, how to write a player simulator, a stress test for a maxed-out build, and the four holes it found. With a QA checklist.
-
A Bug Reached Production: How QA Gets Through the Postmortem Without Becoming the Culprit
A missed bug in production is the moment a tester is pulled either to defend themselves or to beat themselves up. Both paths lead nowhere. We cover why 'who is to blame' is the wrong question, what to do in the first hours, how a blameless postmortem works, which action items actually change something, and how to survive in a team that still hunts for a culprit. With a checklist.
-
A retry is not a second operation: testing retries in QA
A practical plan for testing retries: idempotency, timeouts, duplicates, response ordering and recovery after a network interruption.
-
Tokens in logs: how QA can test diagnostics for sensitive data leaks
A practical test plan for logs, analytics and crash reporting: synthetic markers, error paths, nested fields, account switching and event delivery checks.
-
QA Burnout: Why Testers Burn Out Differently — and What to Do About It
Burnout in QA has its own triggers: you're the eternal bearer of bad news, you're the bottleneck before every release, and 'caught a bug' is invisible work while 'missed one' is public blame. We break down the QA-specific causes, early signs, what actually helps (and what doesn't), an 8-point self-check, and what to ask your lead in a 1-1.
-
Visual Regression Testing: Tools and Approaches in 2026
Functional tests are green but the layout broke: a button shifted off-screen, text is clipped, the theme is broken. That's what visual regression testing catches. We cover what it is, why raw screenshots flake, and the 2026 tools: Playwright toHaveScreenshot, Lost Pixel, Percy, Applitools Eyes, Chromatic — a matrix and who should pick what.
-
Page Object Model: UI Test Architecture So You Don't Drown in Maintenance
Locators and steps right inside tests are a time bomb: change one button and you fix it in 50 places. Page Object Model: a class per page encapsulates locators and actions, tests call methods. What belongs in a Page Object, what doesn't, Component Objects, fluent/loadable, anti-patterns, and when POM is overkill.
-
Testing Mobile App Interruptions and Lifecycle
A mobile app never runs in a vacuum — the OS interrupts at any moment, and that's where the bugs hide. Interruptions (calls, push, notification shade, split-screen), lifecycle and background process kill, rotation, network drops, low-memory kill and battery saver, revoked permissions. A checklist and how to reproduce it all.
-
Bruno vs Postman vs Insomnia: Which API Client to Pick in 2026
Postman went cloud-first with a mandatory login — teams are migrating in droves. A 2026 comparison of three API clients: Postman (powerful but cloud-first and vendor lock-in), Bruno (open-source, offline, collections as .bru files in git), and Insomnia. A matrix, what matters for QA, and how to move off Postman.
-
How QA Talks to Developers: «It's Not a Bug», Priorities and Tone Without War
Half of QA's job isn't finding a bug — it's getting it fixed. How to answer «it's not a bug, it's a feature», how severity differs from priority, how to write a bug report that prevents arguments, keeping the tone «the behavior is broken, not you broke it», what to do about «can't reproduce», and when to escalate.
-
Waits in UI Tests: Why Tests Flake and How to Wait Right
The #1 cause of flaky tests is bad waiting. Why sleep() always loses, why implicit wait is treacherous, how to wait on a condition with explicit wait, what auto-wait changes in Playwright/Cypress, and how to rewrite a flaky test from a timer to a state.
-
A Checklist for Testing Dates, Time and Time Zones
Dates are a source of bugs that surface in production six months later. A practical checklist: storing in UTC, time zones, daylight saving (DST), date formats, boundaries (midnight, end of month, Feb 29), calculations across DST, relative time, and how to reproduce it all.
-
Playwright vs Cypress vs Selenium in 2026: Which to Pick for E2E
A 2026 comparison of the three main E2E frameworks: Playwright (multi-browser, auto-waiting, Trace Viewer, the default for new projects), Cypress (best DX and time-travel debugging), and Selenium (the W3C standard, most languages and Grid). A difference matrix, who should pick what, and how not to get the choice wrong.
-
Ariane 5, Flight 501: How One Overflow Blew Up a Rocket in 40 Seconds
On 4 June 1996, the first Ariane 5 self-destructed 37 seconds after launch. The cause: an overflow converting a 64-bit float to a 16-bit int in reused Ariane 4 code. A first-person breakdown: what happened, why redundancy didn't help, and six QA lessons on code reuse, boundaries, dead functionality, error handling, and testing in the real configuration.
-
Proving QA's Value: Metrics and Impact That Management Actually Sees
QA is often seen as a bottleneck and a cost center, and "found N bugs" is a bad metric. A first-person take: what NOT to measure (bug counts, test-case counts, hours), what to show instead (escaped defects, prevention, risk coverage, speed with quality), the cost of a bug by stage, and how to communicate in business language. With a checklist to make QA's impact visible — and turn it into a case for promotion.
-
API Test Automation: Where to Start and What to Cover in 2026
API tests are the base of the pyramid: faster and more stable than UI, catching logic bugs earlier and cheaper. A first-person take: what to check beyond 200 (schema, error paths, authorization, boundaries, idempotency), data setup/teardown and isolation, validating the contract against OpenAPI/JSON Schema, and the 2026 toolset (Playwright request, pytest+httpx, REST Assured, Hurl, Schemathesis). With a good-API-test checklist.
-
Testing Money and Numbers: A 35-Point Checklist of Where It All Breaks
0.1 + 0.2 ≠ 0.3 — and that's just the start. Money and numbers are a minefield: float error, rounding, locales, currencies, boundary values. A first-person take: why money isn't stored in float, rounding and splitting an amount, locale formatting, currency decimal places, user input, and the business logic of discounts and taxes. With a flat checklist.
-
How to Test a Mobile Game's Economy and Catch Cheaters
A game's economy is the prime target: every cheat hits revenue directly. A first-person take: why you can't trust the client (server authority), duplication bugs and purchase idempotency, device-clock manipulation, save-file editing, negative balance and overflow, fake IAP receipts, and cheat tools. With a checklist of attacks QA must run.
-
Test Reporting in 2026: Allure vs ReportPortal vs Currents vs Native Playwright
"Green/red in the console" isn't a report. Your team and manager need run history, trends, flaky detection, and something they can share. A first-person take: Playwright's native HTML report and Trace Viewer, Allure, ReportPortal, and Currents/Cypress Cloud — what each gives you, what it can't do, and who it suits. With a decision matrix and a good-report checklist.
-
Broken Access Control: How QA Tests Authorization (OWASP's #1 Risk)
Broken access control is #1 in the OWASP Top 10, and QA can catch most of these holes without a pentester. A first-person take: IDOR, horizontal and vertical privilege escalation, forced browsing, testing on the backend (not the UI), a role matrix, and token tampering. With a checklist and the usual places it breaks.
-
How to Deliver Bad News: A Bug Before Release, a Slipped Deadline, "Quality Dropped"
QA is the perpetual bearer of bad news, and HOW you deliver it decides whether you're heard or remembered as the one who always whines and "blocks the release." A first-person take: the fact → impact → options → recommendation formula, data instead of emotion, escalation without drama, the "I surface risk, I don't block" framing, and speaking the language of a developer / manager / stakeholder. With a checklist and phrase templates.
-
Locators That Survive a Redesign: A Selector Strategy for UI Automation
UI automation fails from brittle locators far more often than from real bugs. A first-person take: selector priority (role/label → data-testid → text → CSS → XPath last), why positional XPath and auto-generated classes are time bombs, how to agree on data-testid with developers, the dynamic-content and i18n traps, and how it maps across Playwright, Selenium, Cypress, and Appium. With a good-locator checklist and a list of anti-patterns.
-
Transactional Email Testing Checklist: 40 Things People Forget
"It's just an email" — and then the password reset lands in spam, the welcome mail proudly reads "Hello, {{name}}", and the link expires before it even arrives. A first-person take: trigger and content, deliverability (SPF/DKIM/DMARC, spam), links and tokens, rendering in email clients (dark mode, images off, Gmail/Outlook), timing/duplicates/retries, localization and unsubscribe. With a flat checklist.
-
Interruption Testing in a Mobile Game: A Call, a Backgrounded App, and a Lost Session
The player is on the deciding move — then a call comes in. They return, and the progress is gone, the audio is silent, the rewarded-ad reward never arrived. A first-person take: the catalog of interruptions (call, push, backgrounding, lock, ad, headphones, split-screen), what actually breaks on resume, iOS vs Android differences, how to reproduce each case, and a checklist.
-
Testing Restore From Backup: The Backup Nobody Ever Restored
Everyone has backups — almost nobody tests the restore. A first-person take: why "backup completed successfully" guarantees nothing; what RTO and RPO are and why you measure them; what actually breaks during a restore (corrupt archive, wrong point in time, drifted schema, foreign environment, secrets); how to run a restore drill; and why you should monitor the restore, not the backup job. With a breakdown of the GitLab 2017 incident.
-
Testing Feature Flags and A/B Experiments: How Not to Ship a Mess of Variants
A flag isn't "on/off" — it's a live branch of code in production that you test in both states. A first-person take: why one flag becomes a matrix of states; where the nasty targeting and sticky-bucketing bugs hide; how to test an A/B experiment as a mechanism rather than a hypothesis; kill switches, zombie flags, and a pre-release checklist.
-
Real-Device Testing: How to Build a Device Matrix and Why Your Phone Lies
Everything ran fine on my Pixel — the reviews said "crashes on launch." Real bugs don't live on your device. A first-person take: why one or two phones lie; how to build a matrix along risk axes (OS, hardware class, vendor/skin, screen, locale) from your own analytics; real devices vs emulators vs cloud farms; what to test specifically on varied hardware (OOM, thermals, vendor process-killing, safe-area, update-over-install).
-
Fuzz Testing: Breaking Input with Garbage to Find What You Can't Catch by Hand
Manual cases check what you thought of; bugs live where you didn't. A first-person take: what fuzzing is and why it has a different oracle (you catch the crash, not the "right answer"); the kinds — dumb, coverage-guided (AFL++/libFuzzer), property-based (Hypothesis/fast-check); where QA actually applies it (parsers, file upload, API by OpenAPI, input fields, business logic); what fuzzing finds that manual cases never do; tools and how to start so it lives in CI.
-
Manual → Automation: How to Make the Switch Without Breaking
"Learn Python and Selenium" is the most common and most useless advice. The switch to automation doesn't break on syntax. A first-person take: the three pits (automating everything, thinking automation is "writing tests", dropping the manual mindset), a route that works (minimal language, start with API tests, then UI with architecture, Git/CLI/CI), why your manual past is an advantage (you know WHAT to automate, you're the oracle, repro steps, exploration), and the transition anti-patterns.
-
UI Test Automation Architecture: Page Object and What Comes After It
A good automation suite is measured not by the number of tests but by the cost of change. A first-person take: what a Page Object actually is (it hides HOW behind WHAT), why assertions inside the object are an anti-pattern, the layers above Page Object (components, API setup, test data), where people over-engineer, and the rule of three against premature abstraction. Plus the test-of-a-healthy-test: it reads like a user scenario, with no selectors in the body.
-
Payment & checkout testing checklist — the cases where money breaks
Checkout is where money and trust meet, yet it's usually tested with card 4242 and the happy path. A first-person take: money as integer minor units, not floats; double charges and idempotency; bank declines as normal, not a 500; 3-D Secure and the abandoned challenge; the webhook as source of truth, not the redirect; recomputing totals and promo codes on the server; PCI and tokenization; network drops at every step. Plus a flat 16-point checklist.
-
LiveOps events — releases without App Review that get the least testing
A live game runs on events: battle passes, tournaments and sales ship via server config with no release and no store review — straight to production, on top of any client version. A first-person take: window boundaries and timezones (UTC+13 and UTC-11), clock manipulation as the main cheat, config landing on old clients, claiming rewards exactly once, "a misplaced comma = top-tier sword for 1 coin", time travel on staging as a must-have, the kill switch, and an event launch checklist.
-
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.
-
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.
-
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.
-
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.
-
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.