Why XP Teams Need Testers
- Definition of Tester
- The Tester's Contribution, Illustrated
- Shun the Dark Side
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Much of the published material on Extreme Programming is aimed at programmers, customers, and managers. Some purists may argue that a tester role is unnecessary in XP projects: customers can write the acceptance tests and programmers can automate them. This can work, and certainly some successful XP projects don't have testers.
We believe, however, that more XP teams can be successful by doing a better job of defining, automating, and running acceptance tests when someone is focused on that role and that this focus helps in other areas as well. If you don't like to think of someone in the tester "role" on an XP project (because the only true roles defined in XP are programmer and customer), think of having a programmer with a "tester focus."
We'll illustrate this point with a true story about a remodeling project Lisa recently experienced, but first let's define what we mean by the term "tester."
Definition of Tester
By the term tester, we mean a person who not only develops and runs tests but has quality assurance and development skills as well. Testers spend a portion of their time actually testing, but they also help customers write stories, and they define acceptance tests and take the lead in automating them.
We're combining what would traditionally be described as both quality assurance and quality control activities. The classical distinction between these two is that quality assurance (QA) aims to avoid the introduction of defects in the first place, and quality control (QC) aims to detect defects that have already been introduced. QA is process oriented; QC is product oriented.
While this distinction is useful for manufacturing, it's less so for software, and our experience has been that either activity alone is generally useless. In any case, XP tries not to overly classify people, because to do so implies that they alone are responsible for coding, testing, analysis, and so on, when XP is all about integrating these activities.
If you're used to thinking of a "test developer," "quality analyst," or "software quality engineer," please mentally substitute your own term for ours. We're using "tester" mostly because it's short, but also because it's an instantly recognized term among software teams. Usually followed by "Oh—them."