Testing Experience Issue 7, September 2009
Issue 7 of Testing Experience appeared in September 2009 with agile testing as its theme. It is remembered for a question that still comes up on teams today: does agile change testing, or can developers carry on handing finished code to a separate test team?
Magazine archiveIssue 7 of 28Updated
Browse all 28 issues
Every issue with its date and theme, and the twelve that have their own page.
Open the issue indexThe agile testing issue
The issue. Testing Experience was a free quarterly magazine for professional testers, published in English by a Berlin testing consultancy and training company and edited by Jose Diaz. Issue 7, dated September 2009, was the third issue of the magazine's second year and the one that took agile testing as its theme. It followed the June 2009 security testing issue and arrived at a moment when many organisations were moving their projects to Scrum, and test teams were asking where they fitted in a cross-functional team that had no box marked QA.
What it covered. The part of the issue that is best known is an argument about whether agile changes testing at all. One position, often stated provocatively at the time, was that nothing really changes: developers write the code and throw it over the wall to the test team, only in shorter cycles. The other is that a cross-functional team cannot hand testing off in that way, and that the tester's work moves into the sprint, beside the developers, from the first conversation about a story. That argument is the issue's lasting contribution. Beyond it, this page does not list the issue's articles or authors.
Throwing code over the wall stopped being a serious position and became an anti-pattern that teams name and design against.
Agile testing, 2009 to 2026
Agile testing in 2009. The vocabulary was still settling. Lisa Crispin and Janet Gregory's Agile Testing, published at the turn of 2009, was months old when issue 7 appeared and gave the community its testing quadrants and its whole-team language. There was no published Scrum Guide yet; teams learned Scrum from courses and books, and the role of the tester was left to each organisation to decide. Two outcomes were common: the mini-waterfall, in which testing was squeezed into the last days of a sprint, and the tester as gatekeeper, signing off stories that developers already considered finished. The agile theme did not end with this issue; it ran through the magazine's later years, and the publisher also supported the wider community through media partnerships such as Eclipse Testing Day.
How the practice changed, 2009 to 2026. The agile practice around testers changed in specific ways. The Scrum Guide was first published in 2010 and revised in 2011, when 'commitment' became 'forecast' and the mandatory release and sprint burndown charts were dropped; the 2013 revision made the definition of done explicit as a shared artefact; the 2020 revision removed the separate 'development team' inside the Scrum team, so that a tester is simply a member of one team accountable for the increment. Crispin and Gregory followed their first book with More Agile Testing in 2014. The Agile Manifesto's principles have not changed since 2001. What changed is that 'throwing code over the wall' stopped being a serious position and became an anti-pattern that teams name and design against.
Where to read about it now
Where to read about it now. For a reader who comes to the subject with the issue 7 question in mind, the tester role in agile teams guide answers it directly: does a cross-functional team still need someone whose job is testing, and if so, what does that person do all week? Table 1 lists the tester's responsibilities against how each is handled in a phased project and in an agile team. Figure 2 breaks a tester's two-week sprint into hours and warns that if the exploratory bar shrinks below 8 hours, stories are shipping without a second pair of eyes. The section on anti-patterns names the two that the 2009 debate was really about: mini-waterfall inside the sprint and the tester as gatekeeper.
Two more guides carry the subject forward. The definition of done guide shows how the testing items get written into the story, sprint and release layers, so that the argument about who tests what does not have to be repeated every sprint. The acceptance test-driven development guide covers writing acceptance examples with the product owner and developers before code is written, which is the most practical answer to the wall: the tests exist before there is anything to throw over it. The Agile Testing hub collects the rest of the material on testing inside agile teams.
Then and now
Guides that continue this subject
- Agile TestingRole of tester in agile teams: what changes and what does not
- Agile TestingDefinition of done: layered checklists for story, sprint, release
- Agile TestingAcceptance test driven development: cycle, three amigos, examples
Questions
Is issue 7 of Testing Experience available on this site?
No. This site does not distribute the original issues. It is an independent knowledge base that continues the magazine's subjects in its own guides.
What did the September 2009 issue cover?
Agile testing. It is best known for an argument about whether agile changes testing, or whether developers can keep handing code to a separate test team in shorter cycles.
Who edited Testing Experience?
Jose Diaz edited the magazine for its whole run, from March 2008 to December 2014. It was published quarterly by a Berlin testing consultancy and training company.
Does agile change testing?
Yes. Testing moves into the sprint and becomes the whole team's responsibility, with testers working beside developers from the first discussion of a story. Handing code over a wall is now treated as an anti-pattern.
Where do I read about the tester's role in agile teams now?
Start with the tester role in agile teams guide, then the definition of done and acceptance test-driven development guides, all in the Agile Testing hub.
