Scrum for Testers

Why it matters

Scrum packs planning, building, testing and review into a few weeks. If testing is the last step of the Sprint, untested stories pile up at the end, half-tested work is called done and defects slip into production. The Scrum Guide says quality does not decrease during the Sprint; that holds only if testing is planned from day one.

Knowing Scrum precisely tells you where to act: business-rule questions in refinement, a broken test environment at the Daily Scrum, a recurring quality problem at the Retrospective. And the Definition of Done gives you a quality bar the whole team agreed to.

Accountabilities, artifacts and their commitments

The 2020 Scrum Guide speaks of accountabilities, not job titles. A Scrum Team is one Product Owner, one Scrum Master and Developers, typically 10 or fewer people, with no sub-teams, so there is no separate test team. Its three artifacts each carry a commitment. The Product Backlog, the ordered list of what the product needs, has the Product Goal, the team’s long-term objective. The Sprint Backlog, the items selected for the Sprint and the Developers’ plan for delivering them, has the Sprint Goal, the single objective for the Sprint. The Increment, a usable and thoroughly verified step toward the Product Goal, has the Definition of Done.

Product Backlog refinement, breaking items down and adding detail, order and size, is an ongoing activity rather than an event, and the cheapest place for a tester’s questions. What each accountability means for you:

• Product Owner: accountable for maximising the product’s value and for managing the Product Backlog, including the Product Goal and the order of items. Questions about business rules and priority go here.
• Scrum Master: accountable for establishing Scrum and for the team’s effectiveness, including getting impediments removed, such as an unstable test environment.
• Developers: everyone who builds the Increment, testers included. They own the Sprint Backlog, instil quality by adhering to the Definition of Done and adapt their plan daily toward the Sprint Goal.

What the tester does in each event

The Sprint contains the other four events, lasts one month or less, and the next Sprint starts as soon as it ends. The Daily Scrum is always 15 minutes; the other time-boxes below are maximums for a one-month Sprint, and in shorter Sprints those events are usually shorter.

• Sprint Planning (up to 8 hours): the team decides why the Sprint is valuable, what can be Done and how. Put testing into the "how": test tasks, test data, environments and regression scope.
• Daily Scrum (15 minutes every working day, for the Developers): inspect progress toward the Sprint Goal and adapt the plan. Say what is tested, what is blocked and what is waiting for testing.
• During the Sprint: test each item as soon as it is ready, not in a batch at the end. Pair with developers, automate checks, explore, report defects, and run confirmation and regression tests.
• Sprint Review (up to 4 hours): the team presents its results to key stakeholders and they agree what to do next. Share what was tested and the known risks, and make sure feedback reaches the Product Backlog.
• Sprint Retrospective (up to 3 hours): the team inspects individuals, interactions, processes, tools and its Definition of Done. Bring evidence, such as escaped defects or waiting times, and propose one concrete improvement; it may even go into the next Sprint Backlog.

Try it: Risk-Based Test Generator Try it: Regression Scenario Generator

The Definition of Done and the tester

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. An item that meets it becomes part of the Increment; an item that does not cannot be released or even presented at the Sprint Review, and returns to the Product Backlog. An organisation’s DoD is every team’s minimum; without one, the team creates its own.

The ISTQB Foundation syllabus v4.0 notes that Agile teams often call their exit criteria the Definition of Done. The tester helps make the DoD checkable, applies it honestly and proposes changes at the Retrospective. A DoD for a bilingual web product might read:

• Acceptance criteria verified on the test environment.
• Automated checks for the new behaviour pass in the pipeline.
• Regression tests for the affected areas passed.
• No open Blocker or Critical defects on the item.
• Arabic and English screens checked, including the right-to-left layout.

Try it: Acceptance Criteria Generator

Worked example: one story through a two-week Sprint

A food-delivery team runs two-week Sprints with the Sprint Goal "Returning customers can reorder a past order in two taps". It is a story like the reorder story in the Agile for Testers exercise; this time, follow where each part of the tester’s work happens in Scrum:

• Refinement, in the previous Sprint: the tester asks what happens if an item from the old order is out of stock or its price has changed. Two acceptance criteria are added (the basket uses today’s prices, and the customer is told which prices changed), and out-of-stock handling becomes its own item.
• Sprint Planning: API checks for the reorder request, test data with a changed price, an exploratory session on the basket and checkout regression join the plan.
• Days 4 to 9: the tester raises missing test data at a Daily Scrum and a developer helps after the event. A defect (the old price is copied) is fixed, confirmation-tested and given an automated check the same day; on day 9 the item meets the DoD.
• Review and Retrospective: a stakeholder’s new request goes to the Product Backlog; the tester shows that three items waited two days for test data, so the team now identifies test data in Sprint Planning.

Try it: User Story → Test Cases Try it: User Story → Test Scenarios

Frequently asked questions

References

• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".