Agile for Testers

Almost every team you'll ever interview with will tell you they "work agile." For a tester, agile is not a meeting schedule or a wall of sticky notes — it's a deal: software ships in small slices every couple of weeks, feedback beats prediction, and quality is the whole team's job. That deal changes what a QA engineer does all day, and this topic is the working vocabulary you'll need from your first standup.

The Agile Idea in One Paragraph

Agile is the iterative arrangement from the last topic, grown into a culture. Instead of predicting everything upfront and executing a year-long plan, an agile team builds a small, working slice of the product, shows it to real people, learns from the reaction, and adjusts — every cycle. Change stops being the enemy of the plan and becomes the input to the next one. Everything else — the ceremonies, the roles, the jargon — exists to serve that loop.

The Vocabulary You'll Actually Use

The most common agile framework is Scrum, and its words will fill your workday. A sprint is the fixed heartbeat — usually two weeks — in which the team commits to a small set of work. The backlog is the ordered to-do list of everything the product might need, from which each sprint draws. Standup you met in Chapter 1 — the daily fifteen-minute coordination. Refinement (some teams say grooming) is where upcoming stories get discussed and clarified before anyone builds them — remember that one, it's about to matter. The sprint review shows finished work to stakeholders, and the retrospective is the team asking itself what to improve — the most QA-flavored meeting in the calendar, since it's literally quality assurance applied to the team's own process.

The other name you'll hear is Kanban: no sprints, just a board of work flowing through columns — to do, in progress, done — with a limit on how much can be in progress at once. Support teams and ops-heavy teams love it. The tester's work is the same; only the rhythm differs.

What the Deal Means for Testing

Here's the clause of the agile deal that rewrites the QA job description: there is no separate testing phase. A story isn't "done" when the code is written — it's done when it's built and tested, inside the same sprint. Most teams write this down as a Definition of Done: a checklist a story must pass before it counts, and "tested" is always on it. Testing doesn't happen after the sprint; it happens continuously during it, story by story, as each one becomes ready.

The second clause: whole-team quality. Developers write automated checks for their own code (Chapter 3 names these unit tests). Petra clarifies acceptance criteria. You bring the testing expertise — the techniques, the exploration, the risk thinking. Quality stops being a department and becomes a property of how the team works, with you as its specialist, not its janitor.

Refinementquestion the stories

→

Planningcommit to the slice

→

Build + test dailystory by story, as ready

→

Review + retroshow, then improve

Shift-Left, Now with a Venue

Chapter 1 gave you the principle — early testing saves money — and its nickname, shift-left. Agile gives it a venue: refinement. When the team discusses a story that hasn't been built yet, a tester's questions are the cheapest testing that will ever happen to that story. "What should happen if the payment succeeds but the email fails?" costs one sentence in refinement. The same discovery costs a bug report during the sprint, and a refund weekend after release.

Restaurants understood this long ago: the good ones taste every dish as it leaves the kitchen, all evening — they don't schedule one big food inspection at closing time. Agile testing is exactly that switch: from inspection-at-the-end to tasting-throughout.

Your First Sprint at Fernway

Fernway runs two-week sprints, and your first one starts with refinement. Petra presents the gift-card story. The developers discuss how to build it. You ask one question: "Can a gift card pay for part of a booking — and if so, what happens to the rest?" Silence. Petra checks her notes: the story doesn't say. Ten minutes of discussion later, the story has a new acceptance criterion, and a bug that would have been built, found, reported, fixed, and re-tested — or worse, shipped — never gets to exist at all.

Nobody will call that moment testing. It didn't involve running anything. But you compared an is (the story as written) against a should (a complete, unambiguous story), found a gap, and got it fixed before it could become expensive. That's the whole craft, performed at the cheapest possible moment — and it's why the next topic is entirely about requirements.