During one of my first test management gigs, I had an unpleasant surprise.
The testing cycle in question was retesting a bunch of bug fixes, and doing regression testing of the affected modules. No other modules were affected by the changes, even indirectly.
Other than a few minor bugs, the tests passed with flying colours, and we happily pushed the build up to UAT.
About half an hour later, an irate project manager arrived at my desk: the acceptance testers had discovered a number of major problems in other parts of the application, problems that sounded hauntingly familiar.
After another hour or so of testing we came to a frightening conclusion: version control issues had caused this build to wipe out over a months worth of fixes in modules that were pretty much done.
The PM’s response: “Why didn’t you test that? You’re meant to be doing regression testing.”
I learned an important lesson that day: always do a full regression.
Unfortunately, that was entirely the wrong lesson.
Regression testing, attitudes to regression testing, and common regression testing practices cause some serious issues for testers and the projects they serve. This series of posts will explore the topic further.
Other posts in this series: