Dated, opinionated, first-person.
Tutorials, deep dives, tool verdicts, and real field notes from working QA engineers — across manual, API, accessibility, security, mobile, performance, AI, and automation.
// explore by QA area
// featured series
All series →Not a loyalty test — a scheduling one. Scripted proves the behaviour you already know to check; exploratory finds what nobody specified. Here's which to reach for, when, and how to blend them in one cycle.
Not rivals fighting over the same budget — different jobs. Automation guards what you already know; manual testing judges what you don't. Draw the line wrong and you get a brittle suite and the important bugs still escaping.
Retesting confirms a fix works; regression checks the fix didn't break anything else. Plan them as one task and the 'we fixed it' build ships a brand-new bug. Here's the split, and how they combine after a fix.
Smoke asks 'is this build worth testing?'; sanity asks 'did this change work?' Both are quick gut-checks at different moments. Use them as gates before the real testing — and stop wasting a full pass on a dead build.
Coverage-based testing tries to touch everything a little; risk-based testing concentrates on what matters a lot. Under a deadline — the normal condition — the default you pick decides whether the bug you miss is the costly one or the trivial one.
The three 'box' terms are interview trivia until you use them right: they describe how much of the code you can see when designing a test, which decides what you'll catch. Most functional QA is quietly grey-box — here's why.
Should testers sit in one QA team or inside product squads? An org-design choice, not a tooling one — it shapes when QA gets involved, how consistent the bar is, and whether testers grow as a craft. The trade is proximity vs consistency.
Given/When/Then isn't automatically better than a plain test case — it buys shared language with non-testers at the cost of ceremony. Whether that pays off depends on who actually reads and co-writes your tests.
The pyramid says most tests should be unit tests; the trophy says integration deserves the bulk. They're really arguing about where bugs hide in modern apps. Let the shape follow your real escapes, not whose diagram you saw first.
Test cases that get read are short, scannable, and written for the person who has to act on them. Here is the format I use.
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
A ten-minute accessibility pass any QA can run before release — keyboard, focus, contrast, and the obvious screen-reader checks.
The auth and session bugs that show up in normal functional testing — no exploit tooling required.
Web-first teams carry assumptions that quietly break on mobile — permissions, offline state, lifecycle, and updates.
What p95 actually means, why averages hide the bugs, and how to read a latency distribution as a tester.
A sign-off checklist short enough that people actually use it — and specific enough to catch the things that block releases.
What separates a portfolio project that gets you an interview from one that screams tutorial-follower.
A practical evaluation pass for AI chat features: hallucinations, refusals, prompt injection, and the cases with no single right answer.
A field-tested approach for testing a story when the acceptance criteria are vague, missing, or contradictory.
The specific bugs that hide in paginated, filtered, and sorted endpoints — off-by-one pages, unstable sorts, and filter leaks.
Tab through the page. That single habit catches more accessibility bugs than most automated scans.
Password reset is a deceptively risky flow — token reuse, expiry, enumeration, and session handling all hide here.
A short, device-real smoke pass: permissions, offline, rotation, interruptions, and the update path.
The average response time is the metric most likely to make a slow system look fine. Here is what to watch instead.
How to prioritise testing when the timeline just got cut in half and everything is labelled critical.
AI writes plausible Playwright tests that pass for the wrong reasons. Here is the review checklist that catches them.
What take-home reviewers actually score, and how to spend your limited time on the parts that count.
A case study: a scheduling bug that stayed invisible until the clocks changed — and the test scenarios that would have caught it.
How to scope a regression pass to the change in front of you instead of re-running the entire suite by hand.
The most common serious web vulnerability is also the easiest for QA to catch: the app serves a record by ID without checking it is yours. Two accounts and a changed number find it.
Authentication asks who you are; authorization asks if you are allowed. Most access-control bugs live in the second question — tested with a written access matrix and a lot of negative testing.
A session that lives too long is a hole, one that survives logout defeats the point. Here is the session-expiry pass — idle, absolute, logout, reset, remember-me, and fixation.
Skip the full registry — learn the dozen status codes that carry real meaning, what each promises, and how to spot when the code and the body disagree.
The API ships weeks before the screen. Test it directly from the contract — the whole bad-input, auth, and edge class is open at the API and invisible once the UI hides it.
Notifications behave differently foregrounded, backgrounded, and killed — and deep-link to the wrong place when they arrive. The killed-app cold start is where it breaks.
The interesting offline bugs are in the transitions, not the offline state: double-submits on reconnect, in-flight requests that die, optimistic UI that never rolls back.
A bug report exists to get the bug fixed. Specific title, minimal repro steps, explicit expected-vs-actual, evidence, and environment — the format that prevents "can't reproduce".
Catch the blatant screen-reader failures in fifteen minutes with the reader already on your machine — meaningful names, sensible images, labelled fields, announced changes.
Forms break accessibility hardest — labels, required state, announced errors, focus management, and keyboard-operable custom widgets. The form-specific pass.
Load testing is one type of performance test, not the whole thing. A single user can have a performance bug. Match the test (load/stress/spike/soak) to the risk.
A test strategy is a short set of project-specific decisions, not a generic thirty-page document. Scope, risk, levels, automation split, data, ownership, and what "done" means.
Not yes or no — which coding and for what. Reading code and light scripting help every tester; automation is where the roles are. Coding extends testing, doesn't replace the judgement.
LLMs can't reliably separate instructions from data, so user input can hijack the model. Direct and indirect injection, what to check for, and how to report it QA-safe.
A screenshot isn't a repro when outputs vary. Capture the full assembled prompt, retrieved context, model version, and parameters so an AI bug is actually reproducible.
Every checkout test was green, but combining two discounts and a gift card drove the total negative — and issued credit. A case study in testing invariants, not just features.
Items vanished and duplicated on scroll; the frontend took the blame for two sprints. The cause was an unstable API sort over a non-unique key. Follow the symptom down the stack.
A negative quantity on a "remove stock" action inflated inventory and caused overselling. The feature worked; the absent negative test did not. Test the negative space at the endpoint.
A custom dropdown worked for everyone who tested it — because everyone used a mouse. Keyboard users hit a dead end on a required field. The cheapest check would have caught it.
On office Wi-Fi the payment flow was flawless; on cellular it double-charged. A client timeout shorter than real latency plus no idempotency, hidden by never testing a slow network.
A charter-driven, time-boxed template for exploratory testing: 5 minutes to charter, 35 to test, 10 to debrief — and notes someone can read.
Focus order is the route a keyboard user takes through your page. When it's wrong the page looks perfect and becomes unusable — and scans don't catch it.
The OWASP Top 10 translated for QA: what each category means for flows you already test, and the one check you can run without being a pentester.
The full multi-factor auth test surface: bypass, wrong/expired/reused codes, brute-force lockout, recovery, and the usability cases most teams skip.
Permission bugs live in deny, revoke, and 'ask every time' — not the grant happy path. The per-permission, per-platform matrix that catches them.
QA fresh-installs; real users upgrade in place over old data. Test the upgrade path — schema migrations, stored settings, sessions, multi-version jumps.
Not a full load test — a fast, fixed, repeatable check on a few critical endpoints, compared to baseline, that catches gross regressions before sign-off.
A green suite confirms only what you thought to check. Readiness adds coverage-vs-change, accepted risk, observability, and non-functional signals.
Concrete test cases for AI hallucination — unanswerable questions, false premises, invented entities, citations — and how to judge answers with no 'correct' value.
A green suite, a flawless demo, and a permission check enforced in the UI but not the API — exposing every customer's data. Caught the day before release.
A single intermittent test trained a team to re-run, then ignore, then merge through every red build — until two real regressions slipped through.
Two days of regression, signed off green, and a regression shipped in the most-used feature. The tests weren't wrong — they were testing a stale picture.
Cut a dreaded two-day regression to an afternoon — and caught more — by weighting on risk, automating the stable core, and pruning dead cases.
A 30-second readiness check before accepting a ticket into QA — testable criteria, defined edge cases, reachable build, known data — that replaces a day of back-and-forth.
Three different tools on a spectrum from prescribed to open: when to write a scripted case, a coverage scenario, or an exploratory charter.
The working log that isn't a bug report or a test case — coverage, open questions, un-reproducible anomalies, painful setup — that makes a tester faster and more credible.
API suites fail on shared, stale, order-dependent data more than on wrong assertions. The own-your-data strategy — independent, unique, cleaned — that keeps them reliable.
Test the full rate-limit contract — enforcement, 429, Retry-After headers, recovery, scope — with a low configurable limit and a dedicated key, not by flooding shared staging.
An OpenAPI spec is a ready-made test plan — every param and status code is a case — and its gaps (missing errors, unbounded fields, drift) predict the bugs.
Not winner-takes-all — Postman for exploring and sharing, REST Assured for the durable automated suite in CI. The dividing line is lifespan and automation.
Concrete, reusable accessibility cases for the two highest-consequence flows — keyboard completion, labels, announced errors, focus management — where a barrier blocks a core task.
Automate the mechanical (axe/lint: alt, labels, contrast) and spot-check the obvious in a PR; route keyboard, focus, and screen-reader testing to QA on a real build.
Treat the auth token as an input: test that it expires, dies on logout, can't cross scope or user, doesn't leak, and rejects tampering — all with your normal API client.
A security report has extra duties: private channel, impact over exploit, test data only, redacted evidence, clear severity — getting it fixed without making it worse.
Fragmentation, permissions, system-back, lifecycle, hardware layout, and notifications diverge between platforms — so a pass on one isn't evidence for the other.
Not a purity contest — emulators for functional/UI/CI, real devices for performance, sensors, network, and sign-off. Decide per test whether the check needs real hardware.
Which k6 metrics matter and which mislead: check the error rate first, read p95/p99 not the average, confirm the load profile, and compare to a baseline.
Dead buttons, random logouts, missing data — often timing problems in disguise. The tell is intermittent and worse under load; check latency before debugging logic.
Derive thresholds from user expectation, today's baseline, and business impact — set on p95/p99 with an error-rate gate, tiered by criticality — not a made-up 'under 2s'.
A short, risk-first status format: lead with a one-line risk verdict, then what's at risk, key findings, light coverage numbers, and explicit asks — built to drive a decision.
Frame it as risk for the owner to decide, not a veto: specific, reproduced, impact-led, with options attached — surfaced early, not as a sign-off-meeting ambush.
Write an operating manual for the arriver, not a diary: current state, setup, known issues with status, gotchas, and pointers — so someone can take over without asking you.
Tool-list-as-skills, duties not achievements, no quantified impact, generic and untailored — and the reframe that fixes them: prove you're good at testing, don't describe the job.
Senior interviews assess judgement, prioritisation, and influence — not deeper tool trivia. Prep risk-based reasoning, trade-off thinking, and stories of influencing decisions.
Use STAR to keep a bug story focused on your judgement: brief Situation and Task, an Action with reasoning, and a Result with impact — and pick a bug that shows thinking, not luck.
An honest map of QA's branches — deepening manual, automation, SDET, lead, manager — each rewarding different strengths, none 'up' from the others. Choose by what you like doing.
Get the speed of an AI agent on your test repo without the mess: work on a branch, review every change like a junior's PR, and make tests fail first to catch assert-nothing tests.
AI covers the expected cases fast and misses the suspicion-driven ones that catch bugs. Division of labour: let it handle breadth of the predictable; you handle the unexpected.
A dated June 2026 snapshot: AI became a normal tool and testing-AI a normal job; the fundamentals didn't budge; 'AI replaces QA' is still a slide.
A dated June 2026 take: AI is reshaping QA roles, not eliminating them — eating the mechanical middle, raising the value of judgement, and re-pricing which skills pay.
A dated June 2026 retrospective: shift-left landed as a sensible default oversold as a revolution — real early-bug wins, real damage where it meant 'delete QA'.
A dated June 2026 landscape: web E2E consolidated, API stayed code-first+GUI, performance went lightweight, mobile stayed fragmented, and AI became an authoring feature not a category.
Most teams over-abstract too early. Four custom commands are worth writing on every Cypress project — login, seed, intercept, visit. The rest can wait.
Cypress retries commands until they pass or time out — but only some commands, and only some of the time. Understanding which is the difference between solid tests and flaky ones.
POM was a Selenium-era solution to a Selenium-era problem. In modern Cypress and Playwright, custom commands and locator helpers cover 90% of what POM was supposed to give you.
After shipping production suites in both, here's the honest breakdown — where Playwright pulls ahead, where Cypress still wins, and the single factor that should actually decide it.
Six months from your first if-statement to your first paid automation contract — if you focus. Here's the path I'd take if I were starting today.
Our CI was failing 18% of runs to flakes we'd stopped looking at. One week, four changes, no new tests. Here's what we actually did.
Cypress has three features that look similar but solve completely different problems. Fixtures are static data. Tasks are Node-side escape hatches. Intercepts are network shape. Here's the boundary.
cy.intercept is the most powerful command in Cypress and the one teams most often misuse. Here's the playbook: when to alias, when to stub, when to spy, and the race-condition-shaped bug that intercepts usually catch.
The Playwright trace viewer is the single feature most arguments for Playwright should lead with. Most teams use 10% of it. Here are the five patterns to look for in every trace.
Most explanations of Playwright fixtures lean on React-hook metaphors that miss the point. Fixtures are scoped factories. Here's what to do with them and the three every project should have.
Cypress retries commands; Playwright auto-waits on actionability. Same problem, different solution. Here's what Playwright is actually doing when you call .click().
Cucumber and Gherkin make sense when non-technical stakeholders write tests. They don't make sense when engineers write tests for engineers. Here's the pragmatic test: who actually reads your tests?
There's a take going around that data-testid 'couples tests to implementation.' It's exactly backwards — data-testid is the only selector explicitly decoupled from implementation.
The unit-test-runner version of the Playwright vs Cypress post. I've shipped both in production. If I were starting fresh today, Vitest. Here's why, with real numbers.
Flaky tests don't cost you in CI minutes. They cost you in developer trust. And the compounding interest on lost trust is the most expensive tax in engineering.
I've run production Cypress and Playwright suites in both GitHub Actions and CircleCI for the last year. Here's where each one pulls ahead, where each one tripped me up, and the single factor that should decide it.
The SDET interview loop is four rounds in a trench coat: live coding, system design, framework selection, behavioural. Each round tests something different. Here's what each one is actually looking for.
The transition from SDET to QA Lead is brutal in a way the title doesn't telegraph. You stop being measured on what you ship and start being measured on what your team ships.
AI writes 80% of a test 80% of the way, and the remaining 20% is exactly the part that makes it a test. Where AI saves time, where it's a trap, and the distinction that separates the two.
The practical playbook for AI-assisted test writing in 2026. The prompts that work, the prompts that don't, and the human-in-the-loop checkpoints that keep AI from writing tests that pass for the wrong reasons.
axe-core is the engine behind most accessibility testing in 2026 — and it's surprisingly approachable. Here's a practical walkthrough of integrating axe with Playwright, what it catches, and what it misses.
A 100 Lighthouse accessibility score doesn't mean your site is accessible. The score is a smoke alarm — useful, but not a test. Here's what it actually measures, and what you still need to check manually.
The Cohn test pyramid has been gospel since 2009. It was a useful heuristic for a 2009 monolith Java app. It's been quoted unchanged ever since — and most modern stacks don't fit its shape.
Three tools, three very different bets on what API testing should feel like. I've been comparing them for teams who want to move off ad-hoc curl scripts, and here's the pick.
Mobile test automation is the last frontier where 'just pick the obvious tool' doesn't apply. Three credible options in 2026 — each making a different bet. Here's the comparison.
The 40-page IEEE 829 test plan: written once at kickoff, opened twice during the project, abandoned after release. There's a single-page replacement that teams actually update.
Wiki pages about APIs go stale in three months. The API test suite gets opened every single day. Write tests that read like documentation — and stop writing the wiki.
Four contenders for visual regression in 2026. The dollar cost is easy to compare; the review-fatigue cost is the one no one warns you about. Here's the comparison and the pick.
Contract testing is two things wearing one name: a model and a tool. The model is genuinely useful; the marketing for the tool oversells where it fits. Here's the model, separated from any vendor's pitch.
The pitch: 'run load tests on every PR.' The reality: you'll have flaky thresholds in three days and disabled tests in two weeks. Here's the four-tier strategy that actually survives.
Most 'REST vs GraphQL' content is about API design. The testing perspective is different — query construction, schema-aware tooling, the N+1-shaped test bug, and why GraphQL flips the test pyramid.
What automation replaced was regression checks — running the same path repeatedly. What it didn't replace, and can't replace, is human intuition trying to break a product.
Three load-testing tools with three radically different ergonomics. JMeter has the 2004 XML/GUI legacy. Gatling stakes everything on Scala. k6 is the JavaScript-first newcomer. Here's the pick.