What I check before saying a story is ready for QA

There's a quiet tax in most teams: stories get thrown over the wall to QA before they're actually testable, then bounce back and forth while everyone figures out what "done" was supposed to mean. The fix isn't more testing — it's a thirty-second readiness check before you accept the ticket. If it doesn't pass, the story goes back before you've sunk an afternoon into it. This is the practical front end of testing when requirements are unclear: the cheapest time to surface ambiguity is before you start.

The check, in order

Can I tell what "working" means? If I can't state the expected behaviour in one sentence, the acceptance criteria aren't done. Vague criteria don't produce passing tests; they produce arguments about whether a bug is a bug.

Is it actually deployed somewhere I can reach? "It's ready" and "it's on an environment with the right data and feature flag on" are different claims. I confirm the build, the environment, and the flag state before I start, not twenty minutes in.

Do I know the data and preconditions? What account, what role, what state does the feature assume? A story I can't set up is a story I can't test. If it needs a specific data shape, that's part of ready.

Are the edge cases someone's decision, not mine to guess? What happens on empty, on error, on the unhappy path — is that specified, or am I about to invent the spec by filing bugs? I'd rather ask now than report "bugs" that are really undocumented decisions.

Story-ready-for-QA check

• Acceptance criteria state expected behaviour I can verify, not just "build feature X"
• The unhappy paths (empty, error, invalid input) have a defined expected behaviour
• It's deployed to a reachable environment with the right feature-flag state
• I know the account/role/data needed to exercise it
• Designs/specs match what's actually built (or the diffs are noted)
• Dependencies (APIs, third-party, other stories) are done, not in-flight
• I can write the test cases from the ticket without guessing

Why this isn't gatekeeping

It can read as QA being difficult, so the framing matters: this is about not wasting everyone's time. A story that bounces three times because the criteria were vague cost more than the thirty seconds it takes to catch that up front. When I send one back, I send it with the specific gap ("what should happen when the list is empty?"), not a blanket "not ready" — so it comes back fixed once, not re-guessed. The goal is the same as a good bug report: make the next step obvious and unambiguous.

The teams that skip this don't test less — they test the same story several times as it ping-pongs. A readiness check turns that into a single clean pass.