Regression Testing in the Agile World
Regression testing is an age old practice in the discipline of software testing. It ensures that something that worked in the past has not been broken because of newer changes in the product. Regression testing has been a recommended testing practice, even in the days of waterfall development.
However, it was often not carried out, largely due to a lack of time and especially when the core functional testing was itself relegated to the final stages of the release cycle. The value of regression testing should not be underestimated; some have experienced the hardships of not undertaking it—with overwhelming challenges to face at release time.
The importance and usage of regression testing have grown in the past decade with the increased adoption of agile development methodologies. This growth can largely be attributed to end user expectations and how dynamic the development landscape is in responding to changes required in the product. Although the value of regression testing is better understood in the agile world with its short milestones, teams are always on the lookout for ways to improve the efficiency of their regression test effort.
Since regression tests are often part of a growing test suite that needs to be run regularly to monitor existing functionality, they have over time become a great target for test automation. The automation return on investment is very high for regression tests, but teams have begun to appreciate the need to balance and mix the right amount of manual tests to realize the full potential of a regression test pass. To make the most of a test effort, it is important to identify the right set of tests for a regression test suite.
With test teams increasingly embracing exploratory testing, one useful practice is to create new tests for valid bugs found through such testing to add to the regression suite to ensure they are not missed in subsequent test passes. Traditionally, when defects are resolved, the tester verifies not only the core fix but also surrounding areas that might be impacted by the fix—which is why the effort is called defect regression.
A useful practice here would be to engage the developer by giving him a small suite of regression tests to try even as the bug is being fixed, thereby increasing the chances of a more robust bug fix. Such practices go a long way toward helping the team understand the value of regression testing in a time-crunched agile cycle and help distribute the workload—unlike in the waterfall days where regression testing was often bypassed due to a lack of time and despite the understanding of the value it could generate.