Yesterday you read Tumble Kitchen like a contract and wrote down at least eight promises. Today you go to where those promises are born on a real team: the user story.
Here is a user story, the shape work arrives in on most teams (usually in Jira, the tool many teams use to track work):
As a shopper, I want to sign in to my Tumble Kitchen account so I can reorder my usual dishes.
Three lines. The developer reads it and starts building. Most new testers read it, think “sign-in, fine”, and wait for something to test. The story is the something. Your work starts now, before any code exists.
Interrogate the story
A story has a shape: as a who, I want what, so that why. Each part earns questions:
- What does “shopper” mean here? Anyone, or only people who already registered?
- What identifies them? Email and password? What are the password rules?
- What happens when the email is wrong? When the password is wrong? Is the error message different, and should it be?
- What if the email is valid but formatted oddly, like julia+test@example.com?
- What happens after five wrong attempts?
- And the “so that”: after sign-in, can they actually reorder? If sign-in works but reorder fails, the story failed.
Six questions from three lines. Notice that not one of them needed technical knowledge. They needed you to take the story seriously, word by word.
Check the acceptance criteria
Acceptance criteria are the short list attached to a story that says “done means these things are true”. For our story they might read:
- Sign-in requires a valid email format.
- Password must be 8 to 64 characters.
- A wrong email or password shows a clear error and does not reveal which one was wrong.
- A signed-in shopper sees their name and can reorder.
Two moves, every time. Turn each criterion into at least one test, and hunt for what is missing. The first move is mechanical, and tomorrow you do it properly. The second move is where testers separate themselves.
Read that list again, slowly. It says nothing about attempt limits. Nothing about what the “clear error” actually says. Nothing about staying signed in after a refresh. Each silence is a decision someone will make by accident later, in code, under deadline, and accidental decisions are where bugs live.
Raise the gaps in refinement
Refinement is the meeting where the team reads upcoming stories together and agrees what done means, before anyone builds anything. It is the cheapest room in the building to find a bug in.
A missing acceptance criterion caught in refinement costs the team a five-minute conversation. The same gap caught after release costs real users.
Asking “what happens after five wrong attempts?” in refinement makes the team decide on purpose. Not asking means the code decides by accident. The best QA work happens before a single test is run, and this is what that sentence means in practice.
Do this today
Two lists, twenty minutes, on the sign-in story above:
- Take the four acceptance criteria and write one test idea for each. One line per idea, plain words; full test cases are tomorrow’s job.
- Write at least three missing criteria as questions you would ask in refinement. I have named some of the gaps already; find at least one I did not.
Keep both lists with your promise list from yesterday. Tomorrow the test ideas become real test cases, written so a stranger could run them.