Agile for Testers
Almost every NZ tech job ad mentions Agile or Scrum. Learn what those words actually mean, where testers fit in, and how to add value from day one of a sprint.
1 The Hook
Sarah started her first QA job at a Wellington fintech. On day one, her manager said: "We're Agile. You'll pick it up." Three sprints later, Sarah was still confused. She was testing features after developers had moved on. She was finding bugs in code written two weeks ago. The team saw her as a bottleneck.
The problem wasn't Sarah. She was testing at the end of the sprint — the old Waterfall way — inside an Agile process. Once she learned where testers actually add value in Scrum, she became one of the team's most valued members.
This module is what Sarah wishes she'd had on day one.
2 The Rule
In Agile, quality is the whole team's job. The tester's job is to make quality visible early.
You are not the "quality police." You are the person who asks questions before code is written, who finds ambiguity in requirements, and who gives fast feedback so the team can fix things while they're still cheap to change.
3 The Analogy
A kitchen brigade in a busy restaurant.
In a fine-dining kitchen, the sous chef doesn't wait until the dish is plated to taste it. They taste the sauce while it's reducing. They check the fish while it cooks. They catch problems early because fixing a sauce is fast; sending a dish back from the table is expensive. Agile testing is the same. You don't wait for the "finished" product. You test ideas, requirements, and code as they're being made.
4 Watch Me Do It
Here's how a tester contributes throughout a two-week sprint.
- Sprint Planning — Ask Questions The team picks user stories for the sprint. Your job: read each story and ask what isn't said. "As a user, I want to reset my password" — what about users who never received the original email? What about account lockouts? What if the link expires? These questions prevent bugs before code is written.
- Daily Stand-up — Speak Up Each morning, the team answers three questions: What did I do yesterday? What will I do today? What's blocking me? As a tester, you might say: "Yesterday I tested the login flow and found a session bug. Today I'll verify the fix and start on the registration flow. I'm blocked waiting for test data in the staging environment."
- During the Sprint — Test Continuously As soon as a developer has a feature ready, test it. Don't wait for "testing day." Give feedback within hours, not days. The developer still has the code fresh in their mind. Fixes are fast and cheap.
- Definition of Done — Hold the Line Every team has a Definition of Done (DoD). It might say: "Feature is coded, unit tested, reviewed by a peer, tested by QA, and deployed to staging." You are the gate for the "tested by QA" part. If it hasn't been tested, it's not done.
- Sprint Review — Demo with Confidence The team shows working software to stakeholders. If you tested it, you know it works. You can speak to what was tested, what edge cases were covered, and what risks remain.
- Retrospective — Improve the Process What slowed testing down this sprint? Was the staging environment unstable? Were requirements unclear? Speak up. Agile is about continuous improvement, and that includes how you test.
| User Story | As a customer, I want to apply a promo code so that I get a discount. |
|---|---|
| Tester Questions |
1. What happens if the code is expired? 2. What happens if the code is already used? 3. Can I stack multiple codes? 4. What if I enter the code in lowercase? 5. Does the discount show before or after GST? 6. What happens if I remove the code after applying it? |
When Agile breaks down: A team says they're "Agile" but in practice, developers finish all features first, then testers get two days to test everything before release. Developers have moved on to the next sprint. Bugs found in testing cause panic; the team blames QA for slowing things down. What went wrong?
| What Agile Should Be | What This Team Actually Did | Why It Failed |
|---|---|---|
| Tester involved in sprint planning | Tester was excluded from planning; just given list at start | Ambiguities not caught early |
| Features tested the same day they're ready | Features piled up; all testing on Friday | Context-switching and bottleneck |
| Definition of Done includes tested by QA | DoD existed but wasn't enforced; developers moved on | No accountability for testing |
| Daily standups discuss blockers | Standups were 30 seconds, no detail | Tester issues (test env down, unclear specs) hidden |
5 Definition of Ready
You already met the Definition of Done — the checklist that says when a story is finished. Its quieter twin is the Definition of Ready (DoR): the checklist that says when a story is ready to be pulled into a sprint and worked on. If the Definition of Done is the exit gate, the Definition of Ready is the entry gate. Most first-sprint pain a tester feels traces back to stories that were never actually ready.
From a tester's point of view, "ready" means the story is ready to test, not just ready to code. A story you cannot test is a story that will come back to bite you at the end of the sprint.
| Clear and testable | The story describes a behaviour you could write a test against, not a vague wish. "Search returns results in under two seconds" beats "search is fast". |
|---|---|
| Acceptance criteria written | Each story has its own acceptance criteria, agreed before work starts — the pass/fail conditions you will check against. |
| Edge cases named | The obvious "what happens if…" cases (empty input, expired code, no results) have been raised in refinement, not discovered mid-sprint. |
| Dependencies known | Any other story, API, or test data this story needs is identified, so it does not stall halfway through. |
| Small enough | The story fits comfortably in one sprint. A story too big to finish is too big to test. |
| Test data available | You know how to get the data you need to test it — a Kiwi customer with an active KiwiSaver account, a maxed-out promo code, an overdue invoice. |
The tester is the natural owner of "ready". Developers tend to read a story and picture the happy path; you read it and picture the ways it breaks. Backlog refinement — the regular session where the team grooms upcoming stories — is where you turn a half-baked story into a ready one by asking your questions before it enters a sprint.
6 The Blocked-Tester Problem (Your First Sprint)
Here is a trap that catches almost every new tester in their first sprint. The sprint starts. The developers begin building. And you… have nothing to test. Nothing is finished yet. So you sit and wait. By the time features start landing — usually late in the sprint — they all arrive at once, and now you are the bottleneck. This is the blocked-tester problem: dead time at the start of the sprint, a crush at the end.
It feels like the process is broken, and in a way it is. But the fix is not to wait more patiently. The fix is to realise that "nothing is testable yet" is only true if you think testing means clicking a finished screen. There is always work a tester can do.
- Test the backlog, not the build. Read the stories coming up next sprint and apply the Definition of Ready. Write the acceptance criteria. List the edge cases. This is real testing — you are finding bugs in the requirements before a line of code exists, which is the cheapest bug you will ever catch.
- Write your test cases up front. You do not need a finished feature to design the tests for it. Draft the test cases against the acceptance criteria now, so the moment the feature lands you are testing, not planning.
- Get involved early. Sit with the developer building the story. Pair while they code. Many bugs never make it to a build because you spotted the gap in a five-minute conversation.
- Ask for vertical slices. Encourage the team to finish one thin end-to-end slice early rather than every feature half-built at once. A small finished thing on day three is testable; ten half-finished things on day nine are not.
- Sharpen your tools. Set up test data, get the staging environment working, prepare your exploratory testing charters, automate a check you have been meaning to. Dead time is preparation time.
The pattern to remember: a tester who waits for finished features will always be idle early and swamped late. A tester who works the backlog, writes tests up front, and pairs with developers turns that dead time into the most productive hours of the sprint — and there is no crush at the end, because the testing was already half done.
7 When to Use It / When NOT to Use It
✅ Agile practices help when...
- The team releases frequently
- Requirements change often
- You need fast feedback loops
- The team is co-located or uses video calls
❌ Agile struggles when...
- The team is split across time zones with no overlap
- Regulatory requirements demand heavy documentation
- Stakeholders refuse to attend sprint reviews
- "Agile" is used as an excuse for no planning
Before you apply this technique, ask:
- Does your team have daily standups or regular synchronisation points?
- Is your team willing to adopt continuous testing during sprints, not just at the end?
- Do you have a Definition of Done that includes testing checkpoints?
- Can you access staging or development environments quickly to test early?
8 Common Mistakes
🚫 Testing everything at the end of the sprint
I used to think: I should wait until all features are ready, then test them together.
Actually: By then, developers have moved on. Context-switching back costs days. Test continuously as features are delivered.
🚫 Staying silent in sprint planning
I used to think: Sprint planning is for developers to estimate work.
Actually: It's your best chance to prevent bugs. Ambiguous requirements become expensive bugs later. Ask questions now.
🚫 Being the "quality gatekeeper"
I used to think: "If I don't approve it, it doesn't ship."
Actually: Quality is everyone's responsibility. Your job is to make quality visible, not to be a bottleneck. Share risk assessments and let the team decide.
🚫 Treating Agile as an excuse for no process
I used to think: Agile means we test whenever we want, no planning required.
Actually: Agile fails when everyone tests differently or not at all. The team needs shared standards: What counts as tested? What's the Definition of Done? What's out of scope this sprint? When Agile breaks down into chaos, it's usually because testing wasn't made explicit.
When this technique fails
Agile testing fails when your team does not have daily standups or synchronisation points. If the team only meets once a week, you will revert to end-of-sprint testing. Agile also fails when the team waterfall-creeps: they say "Agile" but still do all work before QA signs off. Testing early requires developers to commit to rapid feedback cycles and definition of done checkpoints.
9 Now You Try
Scenario: You are in sprint planning. The team proposes this user story for an NZ accommodation booking site:
"As a traveller, I want to filter accommodation by price range so that I can find options within my budget."
Write three tester questions that would uncover missing requirements or potential bugs.
Suggested questions:
- Is the price range per night or total stay? What if the stay spans a weekend rate change?
- What currency is displayed for international travellers? Is GST included or excluded?
- What happens if no properties match the range — do we show an empty state or adjust the range?
Tip: The best questions often start with "What happens if..." and expose assumptions the team didn't realise they were making.
10 Self-Check
Click each question to reveal the answer.
Q1. What is "shift-left" testing?
Testing earlier in the process. Instead of waiting for finished code, you test requirements, ask questions in planning, and give feedback on designs. Bugs found early are 10-100x cheaper to fix.
Q2. Why shouldn't testers wait until the end of a sprint?
Developers have moved on. Context-switching back to old code is slow and expensive. Continuous testing gives fast feedback while the code is still fresh.
Q3. What is the "Definition of Done" and why does the tester care?
It's the checklist for when a feature is truly complete. If the DoD includes "tested by QA," then untested code is not done. The tester ensures this rule is respected.
Q4. What is the Definition of Ready, and what makes a story "ready" from a tester's view?
It's the entry gate — the checklist for when a story is ready to be pulled into a sprint. From a tester's view, ready means ready to test: clear and testable behaviour, agreed acceptance criteria, named edge cases, known dependencies, and available test data. If you cannot yet write what "pass" looks like, the story is not ready.
Q5. It's day one of your first sprint and nothing is built yet. What do you do?
You test the backlog, not the build. Read upcoming stories and apply the Definition of Ready, write acceptance criteria and edge cases, draft test cases up front, pair with developers as they code, and set up test data and environments. "Nothing testable yet" only means there is no finished screen — there is always tester work that prevents the end-of-sprint crush.