Testing in Agile Projects: Familiarity Breeds Consent

February 6th, 2014 by inflectra

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.

Agile Testing Agile Testing Quality Assurance

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial