English | EN 
There have been some interesting interpretations of what “going agile” mean, and my two favourites are “no more documentation” and “no more testers”. It is the latter I intend to explore in this article but let’s start with the former:
The “No documentation” myth is easier to tackle as it’s based on a genuine criticism of the tomes of documentation produced by waterfall projects. Tomes are rarely read or updated once reviewed and approved. It’s fairly clear to even the most casual observer that the activity of creating this documentation is severely disproportionate to the usefulness of the document delivered.
The (a key?) difference between Waterfall and Agile approaches is not that one has documentation and the other doesn’t. In Waterfall, the requirements documents were written upfront (as tomes). In Agile, the requirements are captured in feature files and live alongside the code as a living document and a constantly updated knowledge repository with each subsequent iteration.
Without requirements being captured in this way Agile would, as could happen in Waterfall, end up creating systems where there was a degree of uncertainty as to what the system is supposed to do. What is actually the case is that the documentation created under an Agile methodology is designed to be more efficient and more effective, with a focus on what is needed and the removal of anything which is superfluous.
And so we can move on to the claim of “No more testers”.
Now there is a degree of truth to this if we consider a tester’s role to remain the same over time, in particular for that to be a role where testing is done manually and at the end of, or at least overlapping with, development activity. In this sense, there is a genuine decline in demand for manual testers.
But saying there will be “no more testers” is a disingenuous summary of this shift as, by logical extension, it implies there will be no testing. Personally, I can imagine less than a handful of scenarios where this might be acceptable but I’d still suggest that even in those scenarios it is wholly inadvisable!
What is supposed to happen is that testing happens earlier, and swathes of it are automated by developers. What we need to remember is that some of this will be unit testing, and it’s not beyond my memory to recall times when some developers did no unit testing whatsoever … so some of this new testing is actually adjusting for a deficiency in old practices!!!
This leaves us with the other part of the equation to contend with, where developers are also automating some system and system integration testing, removing this from the realm of manual testers. I am in agreement that this will reduce the need for manual testers.
But what the sweeping statement of “no more testers” fails to address is the need for quality (or test) professionals are still required to assure the tests. Whilst it’s relatively straightforward to write a piece of code and write some accompanying tests, this is not a cast iron guarantee of quality.
The reality is that testing is not evaporating but it is changing. The Quality Control aspect is being automated, and as much as possible is being shifted left. What remains is Quality Assurance, which takes the expertise of testers and applies it to make sure the correct checks are done and the most appropriate time to give confidence of quality deliverables time-after-time.
This is important and understood on a small scale. Within Sogeti have also attained great success at delivering quality assurance at scale for large organizations.
