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.
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.
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
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.
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.
Password reset is a deceptively risky flow — token reuse, expiry, enumeration, and session handling all hide here.
The average response time is the metric most likely to make a slow system look fine. Here is what to watch instead.
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.
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.
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.
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.
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.
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.
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'.
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.
Senior interviews assess judgement, prioritisation, and influence — not deeper tool trivia. Prep risk-based reasoning, trade-off thinking, and stories of influencing decisions.
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.
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.
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.
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.
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.
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.
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.