You will have noticed a testing theme present in my latest blogs, today’s is no different! I am on a mission to ensure that we do not hand over products to our customers that are less than satisfactory – this means we test, re-test and test again!
Let’s take a look at regression testing.
It is a genuine fear that when a new “improved” solution is built, whether to fix existing bugs or improve on a current system, that existing functionality will be compromised and mulitple new bugs are introduced. This is where regression testing comes into play. After any changes or enhancements are completed the system needs to undergo full regression testing to ensure the following:
No functionality has been lost or compromised
No new bugs have been introduced
The modified system works as specified
Other areas within the software have not regressed or being impacted
It can be difficult to forecast how a change or fix in one part of the system may impact other areas of the software, so running the gauntlet of appropriate tests is important and doing it in a systematic manner. On the MSDN website they suggest creating a library that holds a complete range of test scenarios which can be used at any time. This would assist the developers and testers and help to achieve regression testing while been time efficient. Furthermore, it is good practice to keep a defect register in conjuction with testing processes.
Ultimately, regression testing is the activity that checks quality and controls what goes out the door meets all functional requirements. It is a necessary evil one could say, but the last thing anyone wants is for a customer to feel like they have been given a bug infested piece of software that is worse than what they brought when they came to you for help!