How to test when requirements are unclear
A field-tested approach for testing a story when the acceptance criteria are vague, missing, or contradictory.
Blog
Real stories from real test suites. The numbers, the failures, the fixes that stuck.
A field-tested approach for testing a story when the acceptance criteria are vague, missing, or contradictory.
How to prioritise testing when the timeline just got cut in half and everything is labelled critical.
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.
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.
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.
Dead buttons, random logouts, missing data — often timing problems in disguise. The tell is intermittent and worse under load; check latency before debugging logic.
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.
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.