← back to the section

It is day nine of a ten-day sprint. For eight days there was nothing to check, and today three tasks arrive at once — with the review tomorrow. Some of it you will skim, some you will not get to at all, and part of the work moves to the next sprint together with a question you should have asked on day one.

That is what a sprint looks like when the tester waits for finished work. Most teams work with Agile: the product is built in short cycles, in small pieces, and the most common flavour of that approach is Scrum. In a short cycle waiting does not work — testing happens alongside development, from day one.

one sprint, 10 days: the same development, two ways of testing 1 2 3 4 5 6 7 8 9 10 development F1 cart F2 payment F3 promo code fixes tester alongside story questions cases F1 defects data F2 recheck F3, regression tester waits for the build waiting for it to be done all at once did not fit → next sprint question on the story — day 1answered the same day same question — day 9rework missed the sprint

The frame marks the current day of the sprint. The development lane on top is identical in both cases; what differs is the tester's work. In the middle lane checking follows readiness: F1 is checked on day four, day five goes to the defects it found, day six prepares data for the next task, day eight rechecks the fixes, and days nine and ten take F3 and run regression. In the bottom lane there is nothing to check for eight days, then everything arrives at once on day nine — and part of the work crosses the sprint boundary together with a question that was worth asking on day one.

Sprint and backlog

Work in Scrum is broken into sprints — short stretches, usually one or two weeks, in which the team takes a small set of tasks and gets them to done.

Where do the tasks come from? There's a backlog — a prioritised list of everything the product needs. For each sprint the team takes from the top of it what they can finish. Tasks are often written as user stories — a short description from the user's point of view: "As a customer, I want to pay for my order by card, so that I don't have to use cash."

The key idea: within a single sprint, a task travels the full journey — from discussion to done, including testing. Not "write it this sprint, test it next sprint."

Scrum ceremonies and your role in them

Scrum has several recurring meetings ("ceremonies"). Each one has a role for the tester:

  • Backlog refinement. The team goes through tasks for upcoming sprints in advance: wording is clarified, large items are cut into pieces. Your questions are cheapest here — there is no code yet.
  • Planning. At the start of the sprint the team decides what to take on. Your job is to work out what and how you'll test and how much you can cover; ambiguities in requirements usually surface right here.
  • Daily (daily stand-up). A short daily check-in: "what I did, what I'll do, what's stopping me." You share what you're testing, where you're waiting on fixes and what has stopped the work.
  • Review (demo). At the end of the sprint the team shows what was built. You've already verified it before the demo — no surprises should appear on the day.
  • Retrospective (retro). The team talks about what went well in the process and what to improve. The tester raises quality issues: for example, "tasks arrive for testing on the last day — we don't have time."

Why testing happens alongside development

In the older waterfall approach testing was a separate phase at the end; in a short cycle it is spread across the whole sprint:

  • At the start you review tasks and ask questions (bugs in requirements are caught here).
  • While the developer writes code, you prepare test cases and test data.
  • As soon as a feature is ready — you check it right away, without waiting for the end of the sprint.
  • Towards the end — regression: make sure the new work hasn't broken anything old.

The important takeaway: a tester and a developer are partners working side by side, not an assembly line where one hands over and the other receives.

Definition of Done — when a task is done

The Definition of Done (DoD) is a shared team checklist of the conditions a task must meet to count as complete. "Tested" is usually on the list: for example, "code written, code review passed, tests passed, no high-priority bugs open."

For a tester, the DoD is protection: a task isn't "done" until it's been verified.

Where the sprint is lost

  • Waiting until "everything is done" and ending up with all the work on the last day — that is the bottom lane in the picture.
  • Staying silent in meetings. Planning and the daily are where you ask questions and say what stopped the work; silence postpones the problem instead of solving it.
  • Treating the developer as an opponent. You're working toward the same goal; a bug is not an accusation — it's a shared finding.

In short

  • A sprint is a short stretch (one or two weeks) in which a task travels the full way to done, checking included.
  • Testing does not sit at the end: questions before the code, cases and data while it is written, checking as soon as a feature lands, regression before the review.
  • A question about a requirement asked at refinement or planning costs a conversation; the same question on day nine costs rework that will not fit into the sprint.
  • Every ceremony gives the tester something to say: scope and questions at planning, what is blocking at the daily, quality problems at the retro.
  • The Definition of Done is a shared readiness checklist: while "tested" is on it, unverified work does not slip into a release.
  • By the review everything is already checked — demos hold no surprises.