It’s been 12 years since the Agile Manifesto was created, and the majority of developers have jumped on the bandwagon since then. Agile methodologies are now dominating the software development landscape. It has overtaken waterfall as the dominant approach. But in the rush to implement the agile mindset, something has been overlooked: the tester.
The focus on delivering a good product without endless documentation is undoubtedly a positive move for developers. By keeping the needs of the end user in sight at all times, and by creating feedback loops, projects generally deliver better software, faster than before. Given that the agile methodology was conceived by developers for developers, it left the testers in the dark. As a report from Forrester points out, agile teams must invite testers to the table.
It should be obvious that agile development completely disrupts traditional testing practices, yet many companies have done nothing to update processes or arm testers for the new challenges they are facing.
Imagine a typical scenario on an agile project with a team of five developers and a pair of testers. From the development point of view, five developers can work at a steady, measurable velocity, adding new features to each new build. But that simply isn’t true for testers.
At first, testing each sprint is not a problem, because testers have a limited number of features to test. But as the software grows, they have to test new features, verify bug fixes, and perform regression testing. Everything has to be tested within the sprint timeline; the shorter it is, the more rounds of regression testing are needed. Soon, the test team is bogged down and overloaded.
Automated unit tests developed along with the code help to relieve some of the pressure, but the workload for the testers remains high. How can the same two testers cover all the new features while also doing verification and regression testing? The answer is simple: They can’t.
A different approach
In order to ensure that the quality remains high, management could scale up the test team significantly as the development progresses, but there is a much more cost-effective solution. Regression testing has to be documented and then automated as you progress. There’s no way to write up these test cases or scripts before the code has been delivered.