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 (def.: 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 (more on that another time), 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.
Our mission to helping our customers - large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development and testing lifecycles, so as to decrease the time to market and increase return on investment.
At Inflectra, we are fully committed to provide our customers with the very best products and customer service. We believe in going the extra mile to ensure that each customer is satisfied with our software products. We have the experience and the commitment to deliver the products customers need to deliver their projects and assure quality every step of the way. (Learn More)
We are so confident that you will be fully satisfied with our products that we offer a 30-day, unconditional, money back guarantee! (Learn More)