qa
16 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.
-
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.