Testing inside a sprint, day by day

A restaurant kitchen does not wait until every order is in and then start cooking.

Prep happens before service. Dishes are cooked as the tickets arrive. Anything that takes forty minutes goes on early. Nobody plates twelve mains in the last five minutes, because that is how you get twelve bad dinners.

Testing in a sprint works the same way. "We will test it at the end" is the kitchen equivalent of starting every dish at closing time.

This is the most-asked question in testing and the least written-about. So here is the whole two weeks, day by day.

The two weeks

Say you are the only tester on a team of six engineers, working a ten-day sprint with nine stories in it. Here is what each day is for.

• Day 1, prep. Read every story. Write the acceptance criteria that are missing, and ask about anything ambiguous now, while it costs a sentence instead of a rewrite. Note which stories need test data or a new environment, because those requests have lead times.
• Days 2 and 3, the questions. Engineers are building. This is your cheapest window. Pair on one story, look at a half-built screen, ask what happens when two people do the same thing at once. Bugs found here are conversations rather than tickets.
• Days 4 to 8, the flow. Stories arrive finished, one or two at a time. Check each story's acceptance criteria, then explore around it for half an hour. File as you go, and keep a running list of what is done and what is waiting.
• Day 9, regression. Run the pack. Avoid first-time story testing today. Triage whatever the pack finds, and check the failures against your run history before calling any of them new.
• Day 10, the decision. Re-test the fixes, write the one-page summary, and say plainly whether you would ship it and what is still open.

Why you should care about this

Because the alternative fails quietly, and it always fails the same way.

Testing gets pushed to the end. The end is short. Bugs found on day nine are expensive, so they get deferred. Deferred bugs pile up. The next sprint then starts with last sprint's problems and less time than before.

Nobody decided any of that. It is simply what happens when testing is a phase at the end instead of a thread running through the two weeks.

The version of you that reads the stories on day one and asks two questions costs the team nothing. It is the highest-return habit in this whole layer.

How you make it work

1. Get a definition of ready. Nothing enters the sprint without acceptance criteria and a note on test data. One line in the working agreement, and a large effect downstream.
2. Test in the order things finish. The board is planning. Your queue is reality.
3. Timebox exploration per story. Thirty to sixty minutes, with the charter written down, as in session-based testing. Otherwise the interesting story eats the week and the dull one ships untested.
4. Make waiting visible. A story you cannot test because the data is missing is blocked, on the board, with a name against it. Quiet waiting looks like slow work.
5. Protect the last two days. Say it in planning. Day nine is regression, day ten is the decision. People respect a stated constraint far more than an implied one.
6. Write the coverage gap down. One line per release, covering what you did not reach. Over three sprints that line becomes the evidence for a conversation about capacity.
7. Keep the record as you go. Results against stories, not in your head. It is the same reason a release rests on a record rather than a memory.

Try this today

Write your own sprint on one page. What actually happens now, and what should. It takes ten minutes, and it usually settles an argument the team has been having for months.

The bottom two entries are the ones that change your week. One is a request made while it is still cheap. The other is a fact recorded instead of a worry carried around.

How to show you know it

• A sprint shape you can describe. Saying what you do on day one, day five and day nine, and why, reads as real experience in any interview.
• A recorded coverage gap. One line per release. It shows that you separate what was tested from what was hoped.
• A late-story conversation. For example: "It landed on day nine, so I asked product to choose between forty minutes of testing and holding it." That is a tester who surfaces pressure instead of absorbing it.
• Two questions asked in refinement. The habit that prevents more defects than any tool. Turning a story into cases is where it leads.