Agile Testing
How testing works when there is no test phase. Six guides on the tester's role, the collaborative practices that replace hand-offs, and the artefacts (charters, example tables, a definition of done) that keep quality visible sprint after sprint.
6 guidesUpdated Editorial method
About agile testing
Agile did not remove testing; it removed the phase in which testing used to hide. The tester on a cross-functional team is present from refinement to demo, and the work changes shape: fewer scripted passes at the end, more examples written before the code, more exploratory sessions during the sprint, and a shared definition of what done means. The guides here are for testers and leads making that transition and for teams that made it years ago and have drifted into a mini-waterfall inside the sprint.
The role of the tester in agile teams sets out what changes and what does not, with a before-and-after responsibilities table and the anti-patterns to watch for; it continues the agile testing theme of the magazine's issue 7. Acceptance test driven development covers the discuss-distill-develop-demo cycle, the three amigos session and example tables, and compares ATDD with BDD and TDD. Exploratory testing is a how-to: charter templates, session length, notes, debriefs and how to report the work to management.
Agile program management scales the view to three to eight teams, with integration testing and a program-level definition of done; it continues the subject of the publisher's Knowledge Transfer tutorial on agile program management. Agile inspection is a one-hour sampling technique for measuring requirement quality before a story is accepted into a sprint. Definition of done lays out story, sprint and release layers with the testing items spelled out, and how to audit whether the team follows its own DoD.
Three situations decide where to start. If a plan is due this week, the agile answer is a definition of done with the testing items written in, so open the story, sprint and release DoD layers and then the example table format, which turns a story's acceptance criteria into the cases a plan would otherwise have listed; if a customer still wants a plan document, the one-page plan option in the management hub is written for that case. If the build is red and nobody trusts it, the problem is usually ownership, and the responsibilities table in the tester role guide shows what the whole team owns; run a charter against the failing area to find out whether the failures are real before anyone reruns them. If an audit is coming, the DoD audit section shows how to sample recent stories against the team's own checklist, agile inspection gives a defect density per page for the requirements the auditor will read, and the program-level definition of done covers the case where the audit spans several teams.
The hub connects to the authenticity lane through the practices that replace scripts. Adversarial testing of a detector is exploratory work with a charter: a session on paraphrased, translated and mixed documents finds the region where detection fails, and the session notes become the slices of the next benchmark. Verifying content credentials is written as a tester's session for the same reason, with four outcomes standing in for a debrief. And the disclosure label guide writes its expected results as one row per partition of origin, medium and edit state, which is an ATDD example table under another name; the three amigos conversation that produces such a table is the right place to decide what a label must do on each surface. Two newer guides belong here too: testing deepfake detection as an exploratory and benchmark exercise, and a chain of custody for screenshots and logs from a session, so what a tester found in a charter can be shown later.
The sources cited in this hub are the books the agile testing community argues from: Crispin and Gregory, Adzic, Hendrickson, Bach on session-based test management, Gilb on inspection, Rothman on program management. Where a guide's subject overlaps with automation or technique, it links across to the Test Automation and Testing Techniques hubs rather than repeating them.
All guides
Nothing matches. Clear the filter to see every entry.
Questions
What does a tester do on an agile team?
The tester makes quality a whole-team outcome: shaping stories before they are coded, pairing with developers on tests, running exploratory sessions on every story inside the sprint, owning the automation strategy rather than every script, and reporting risk to the team instead of acting as a gate. Hands-on testing is about 30 percent.
What is the difference between a definition of done and acceptance criteria?
A definition of done is a fixed checklist every increment must satisfy, at story, sprint and release layers, and it applies to all work. Acceptance criteria apply to one story. The sprint layer, for example, requires a green regression run, no open severity 1 or 2 defects and an accepted demo.
How long should an exploratory testing session be?
Between 60 and 120 minutes, uninterrupted. Write a charter in the form explore a target, with resources, to discover information; keep notes of what you tested, found and could not do; debrief with a peer for 15 minutes; and track sessions, coverage and bugs per session.
Is ATDD the same as BDD?
They share the idea. In ATDD the product owner, a developer and a tester agree concrete examples before coding, turn them into automated acceptance tests and demo them once they pass. BDD is the same idea with a stronger shared language, while TDD works at unit level.
