Harbour: one tester, five developers and a signature
At logistics firm Harbour one tester supports five developers. She writes all test cases, executes all system tests, triages every defect, maintains the regression suite and signs a release-readiness sheet that the release manager will not accept without her signature. Developers mark stories done when the code is pushed and smoke-tested locally. The team completes about 27 stories per sprint. She works 50-hour weeks, has cancelled her last six exploratory sessions, and now regularly rejects stories at the end of the sprint, after which developers call her the gate. In the last retrospective two developers said testing is what happens after development, and one asked why the team needs a tester at all if the developer already ran the code. Management's proposed remedy is to add a second tester so the gate can move faster.
1. Explain why a second tester will not fix this, using the role of the tester in an agile team and the idea of a gate in the workflow.
Read the worked answer
Adding a second tester doubles the capacity of a step the team should not have. The problem is not test execution volume; it is that every quality decision is concentrated in one person: test design, triage, regression ownership and release sign-off. A wider gate is still a gate, and it confirms the developers' belief that done means pushed. The evidence is in the symptoms. Twenty-seven stories per sprint pass through one person, so work arrives in a batch and bounces back at the end. Six cancelled exploratory sessions show which activity is sacrificed first under load, and it is the one that generates new information rather than confirming what is already known. End-of-sprint rejections are a batch-size symptom, not a diligence symptom. In an agile team the tester's contribution is information and the conversations that produce it: helping the team ask what could go wrong, turning examples into checks, coaching developers to test at the right level, and exploring what automation cannot judge. Hours spent triaging other people's defects and filling a sign-off sheet are hours not spent on that, and the developer's question, why have a tester if I ran the code, is a fair response to a role that has been reduced to a checkpoint. The release manager's need for confidence in a build is legitimate; the personal signature is only one implementation of it, and a fragile one, because it depends on one person's availability and leaves nothing inspectable behind.
2. Reallocate her current activities: what to delegate, what to stop, what to keep. Give a sequence and the measures you would watch.
Read the worked answer
- Delegate to developers: first-line triage for defects in their own components, writing and maintaining unit and component checks, and running the show-and-tell to the product owner. Pair for the first two cycles so this is coaching rather than dumping.
- Stop: the release-readiness signature as a personal act. Replace it with a generated release checklist plus a short written risk summary owned by the team: what changed, what automated checks cover it, which exploratory sessions touched it, which risks remain open and who accepted them. The release manager gets something auditable, faster and independent of one person's calendar.
- Keep for the tester: exploratory testing on the riskiest behaviour, testability review at refinement, cross-cutting risks such as performance, security and data integrity, and facilitation of the three-amigos conversation. Sequence: sprint 1, pick two stories where a developer does triage while she observes, and start the regression rota with a shared scorecard; sprint 2, move acceptance demonstration to developers and add the risk summary alongside the signature; sprint 3, propose retiring the signature with the release manager co-designing the checklist so the need is met rather than denied. Measures: exploratory sessions restored from zero to two per sprint, number of stories reaching the review already accepted, triage turnaround time, and escape rate before and after. Watch that triage quality does not drop; that is the risk of delegating fastest.