This article discusses the differences between quality assurance and software testing. If the developer uses techniques like TDD to prove that his program can work, you shouldn’t ask him to prove the opposite. This article advocates having a separate software testing function, even if you are using an Agile software development approach like Scrum.
Paul Raymond, Inflectra Corporation, http://www.inflectra.com/
The testing function in Agile projects should not be confused with the Quality Assurance function. If we are not careful, the Agile philosophy will conflate the two, with potentially disastrous results.
It’s easy to say that testing in an Agile development process should be integrated with all process activities. But what does that really mean? It is generally understood that an Agile process will rapidly repeat all project activities in an iterative manner, but does that mean those activities blur into one amorphous Scrum (definition: in rugby – to engage in an ordered formation of forwards in which each side aims to gain control of the ball.) Requirements are requirements no matter which process you use, design is design, coding is coding.
But it has been suggested that testing be fully integrated into the Agile development process so that testers can attempt to prevent defects rather than just try to find them. But this is the thin edge of a slippery slope. If we are not careful, we can lose sight of the true purpose of the testing function and begin to view testing as part of the overall team trying to ship the product out the door quickly. But testers should have the opposite aim: trying to prevent the product from shipping. And they do so by trying to show that it is not ready; that it is not yet production quality; that it has impactful defects and fails to meet requirements.
Test-driven development can be even worse. The primary objective of test-driven development is to create high-quality software that meets the requirements, however, the term ‘test-driven’ encourages the misconception that the resulting code has been tested. It has not. The author of the so-called ‘tests’ is very likely to be the same person – or someone working very closely with the same person – writing the code. Once again, this is someone who is trying to create and deliver the product, not trying to find creative ways to break it. Test-driven development might build-in quality, but it certainly does not deliver tested software.
The key is to recognize the difference between testing and quality assurance. They are and should be separate animals. The quality assurance function tries to prevent defects. The testing function tries to show that they failed. It is quality assurance that should be tightly integrated into Agile iterations or sprints, not testing. While testing must take place as part of the iterations, it must not get too close.
Otherwise the Stockholm syndrome will turn testers into ineffectual figure heads with sympathies for the development team rather than the gatekeepers we need them to be.
About the Author
Paul Raymond is a successful software program manager with Inflectra Corporation. He has extensive experience working with requirements management systems, including DOORS from Telelogic and SpiraTeam from Inflectra. Paul has helped customers in multiple industries take control of their requirements and develop actionable plans for the delivery of software projects on-time and on-budget. This article was originally published on http://www.inflectra.com/Ideas/Entry/154.aspx and is reproduced with permission from Inflectra.