Agile and Scrum for Testers

Most QA and SDET roles today sit inside Agile teams, and most of those teams use Scrum or something derived from it. In this setting there is no separate “testing phase” handed over at the end. Testing happens continuously, and the tester’s influence starts long before any code exists. This lesson explains the Scrum framework from a tester’s point of view and the practices that make testing work in short iterations.

The SDLC lesson introduced Agile as a model; here we go into the day-to-day mechanics.

Agile in one paragraph

The Manifesto for Agile Software Development (2001) values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It explicitly says the items on the right still have value; the items on the left are valued more. For testers this translates into short feedback loops, close collaboration with developers and the business, lightweight but useful documentation, and testing that adapts as requirements evolve.

Agile is a set of values and principles. Scrum and Kanban are frameworks that put them into practice.

Scrum basics

The Scrum Guide (2020 edition) defines Scrum in terms of three accountabilities, five events and three artifacts.

Accountabilities

Accountability	Responsible for	Tester’s interaction
Product Owner	Maximising product value; ordering the Product Backlog	Clarifying acceptance criteria, agreeing priority of defects, accepting or rejecting work
Scrum Master	Effectiveness of the Scrum Team; removing impediments	Raising testing impediments: unstable environments, missing test data, blocked access
Developers	Creating a usable Increment each Sprint	Testers are Developers in Scrum terms: everyone who does the work to create the Increment

The Scrum Guide does not define a “tester” role. That is deliberate: quality is the responsibility of the whole Scrum Team, and people with testing skills are part of the Developers. In practice, teams often still have a QA engineer or SDET, but their job is to bring testing expertise to the team, not to own all testing alone.

Events

Event	Purpose	What a tester does
Sprint	Fixed-length container, one month or less, commonly two weeks	Tests continuously as stories become ready
Sprint Planning	Decide the Sprint Goal and what can be done	Point out testing effort, test data and environment needs; flag stories that are not testable yet
Daily Scrum	15-minute inspection of progress towards the Sprint Goal	Share testing progress and blockers; spot stories piling up for testing
Sprint Review	Inspect the Increment with stakeholders	Help demonstrate; share quality information and known issues
Sprint Retrospective	Improve how the team works	Raise process problems: late handovers, flaky pipelines, escaped defects

Backlog refinement is not one of the five events; the Scrum Guide describes it as an ongoing activity. It is, however, where testers add the most value per hour, as explained below.

Artifacts and their commitments

Artifact	Commitment	Relevance to testing
Product Backlog	Product Goal	Stories and their acceptance criteria are the test basis
Sprint Backlog	Sprint Goal	Testing tasks belong here alongside development tasks
Increment	Definition of Done	Work is not part of the Increment until it meets the DoD, which should include testing

The tester in refinement

Refinement is where stories are clarified, split and estimated. A tester asking good questions here prevents defects rather than finding them later, which is the essence of shift-left.

Useful questions:

• What happens when the input is empty, too long, or in the wrong format?
• What should the user see when the external service is down?
• Who is allowed to do this, and who is not?
• Is there a limit, and what happens exactly at it?
• How will we know this works in production?

Three amigos

A three amigos session brings together business (product owner or analyst), development and testing perspectives to discuss a story before it is built. The output is usually a set of concrete examples that become acceptance criteria and often automated acceptance tests. The number three refers to perspectives, not people.

Testable acceptance criteria

Vague criterion	Testable criterion
Search should be fast	Search results appear within 1 second for 95% of requests at expected load
User-friendly error messages	When the email is invalid, the field shows “Enter a valid email address” and focus moves to the field
Supports large files	Files up to 50 MB upload successfully; larger files are rejected before upload with a message stating the limit

Teams practising behaviour-driven development write criteria as Given/When/Then examples. See Writing Test Scenarios for how to turn criteria into scenarios.

Definition of Done vs acceptance criteria

These are often confused:

• Acceptance criteria are specific to one story: the conditions this story must satisfy.
• Definition of Done applies to every item: the quality standard for anything to be considered part of the Increment.

A Definition of Done that supports quality might include:

• Code reviewed and merged to the main branch.
• Unit and API tests written and passing in the pipeline.
• Acceptance criteria verified; automated where agreed.
• No open defects of agreed severity against the story.
• Accessibility checks run for UI changes.
• Documentation and release notes updated where relevant.

Testing within a sprint

The classic anti-pattern is the mini-waterfall: developers code for eight days, then hand everything to testing on day nine. Testing becomes a bottleneck, bugs are found too late to fix, and stories roll over.

Ways to avoid it:

• Slice stories thin so they can be finished, tested and merged within a few days.
• Limit work in progress. Start fewer stories; finish them together.
• Test as you go. Test on feature branches or preview environments, pair with developers, review unit tests.
• Automate during the sprint, not in a later “automation sprint”. Acceptance tests for the story are part of the story.
• Share testing. Developers can run exploratory checks on each other’s stories; testers can write or review unit-level cases.

Sprint day	Tester focus (two-week sprint example)
Day 1	Sprint Planning: testing effort, data, environments; draft scenarios for top stories
Days 2–4	Test first stories as they reach review; write automated acceptance tests alongside
Days 5–8	Continue story testing; exploratory sessions on integrated features; refinement of next sprint’s stories
Days 9–10	Regression on the integrated Increment; prepare for Sprint Review; retrospective inputs

The whole-team approach

ISTQB Foundation (v4.0) describes a whole-team approach: everyone on the team shares responsibility for quality, and team members with testing expertise collaborate with business representatives and developers throughout. It is a principle, not a job description. The tester’s contribution shifts from executing all tests personally to coaching, designing tests, building automation, and making risks visible.

The Agile testing quadrants

The testing quadrants, originally proposed by Brian Marick and popularised by Lisa Crispin and Janet Gregory in Agile Testing, help a team check that it is not ignoring whole categories of testing.

	Supporting the team	Critiquing the product
Business-facing	Q2: functional tests, story tests, examples, prototypes	Q3: exploratory testing, usability testing, user acceptance testing
Technology-facing	Q1: unit tests, component tests	Q4: performance, security and other non-functional testing

The quadrants are not an order of execution. A team that only invests in Q1 and Q2 automation may ship working features that are slow, insecure or confusing.

Common challenges

• Tester as gatekeeper. If only the tester can declare quality, the tester becomes a bottleneck and a scapegoat. Make quality a team metric.
• No time for regression. Automate critical paths early and keep regression in the pipeline, not in the last days of the sprint. See Regression Testing.
• Unstable requirements. Embrace it, but capture decisions as examples or tests so the current agreed behaviour is always visible.
• Testers left out of refinement. Ask to join. One good question in refinement is worth hours of testing later.

Practice exercise

Your team is in refinement for this story: “As a customer, I want to save my card details so that checkout is faster next time.” The draft acceptance criteria are “Card can be saved” and “Saved card is shown at checkout”.

1. List six questions you would ask as the tester.
2. Rewrite the acceptance criteria as at least four testable criteria.
3. Suggest one item for the team’s Definition of Done related to this kind of feature.

Show a model answer

1. Questions

• Are card details stored by us or tokenised by the payment provider? (Security and compliance scope.)
• How many cards can a customer save? What happens at the limit?
• Can a customer delete or replace a saved card, and set a default?
• What is shown for a saved card: last four digits, brand, expiry?
• What happens when a saved card expires?
• Is the security code required again on each use?

2. Testable acceptance criteria

• Given a successful payment with the “Save card” box ticked, the card appears in Account > Payment methods showing brand, last four digits and expiry.
• At checkout, saved cards are listed with the default card preselected.
• An expired saved card is shown as “Expired” and cannot be selected.
• A customer can delete a saved card; it no longer appears at checkout.
• The full card number is never displayed or returned by any API.

3. Definition of Done item

“Security review checklist completed for any change that handles payment or personal data”, or “API tests assert that sensitive fields are absent from responses”.

Key takeaways

• Scrum has three accountabilities (Product Owner, Scrum Master, Developers), five events and three artifacts. Testers are part of the Developers.
• Testers add the most value early: in refinement and three amigos, turning vague criteria into testable examples.
• Acceptance criteria are per story; the Definition of Done applies to everything and should include testing.
• Avoid the mini-waterfall: thin stories, limited work in progress, testing and automation during the sprint.
• Use the testing quadrants to check the team covers functional, exploratory and non-functional testing.