Agile Testing Guides
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.
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 an argument the magazine's issue 7 was cited for. 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; it recovers a PDF on the subject that the original site hosted.
All 6 guides in this hub
| # | Guide | What it settles | Level | Reading |
|---|---|---|---|---|
| 1 | Role of tester in agile teams: what changes and what does not | When a tester joins a cross-functional agile team, the job title barely changes and the daily work changes almost completely. | Practitioner | 5 min |
| 2 | Acceptance test driven development: cycle, three amigos, examples | Acceptance test driven development (ATDD) turns the conversation about a story into concrete examples before any code is written, then makes those examples the tests that prove the story done. | Practitioner | 5 min |
| 3 | Exploratory testing: how to write charters and run sessions | Exploratory testing is simultaneous learning, test design and execution: you decide the next test based on what the last one showed you. | Practitioner | 5 min |
| 4 | Agile program management: coordinating 3 to 8 teams | One agile team can ship on its own. Three to eight teams building one product cannot, because the interesting problems, integration, dependencies and the release, sit between the teams rather than inside any of them. | Lead | 5 min |
| 5 | Agile inspection: sampling requirements for major defects | Classic inspection reads every page of a specification with a room full of reviewers and takes a week. | Lead | 5 min |
| 6 | Definition of done: layered checklists for story, sprint, release | A definition of done is the team's shared, checkable agreement about what finished means. | Practitioner | 5 min |
Where to start, by the question you have
Agile program management scales the view to three to eight teams, with integration testing and a program-level definition of done; it continues the Knowledge Transfer tutorial that the most linked querystring URL on the old site pointed to. 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.