February 6th, 2014 by Adam Sandman
agile testing quality assurance
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.