Regression Testing: A Necessity for the Progression of Software

Posted in Functional Testing

"Why do we need to test something that is working? There haven't been any changes to this functionality."

The above phrases have been uttered repeatedly by a number of people when discussing regression testing. Do they have a point? Why test functionality that has been working for years and has not received any updates?

The short answer is because the software testing profession is based on minimizing risk and testing to increase confidence. Regression testing is an essential part of the software development lifecycle because working functionality could be affected by new functionality or changes to other areas. Code that is changed to fix an issue in one area could cause bugs to appear in areas meant to go unchanged. Time pressures for coding in a complex software application and inadequate time for thorough testing often have unintended effects. Old defects might creep back into the software due to lack of version control. Moving code to a new environment could also cause a host of issues. If a test has a serious of passes from day to day and suddenly fails after a code change, it's very likely the change caused a regression in the software. It is vital for a business to ensure that developed software still functions properly after any alteration or modification of the system.

Another goal of regression testing is to find new defects in working software. Isn't that an oxymoron, since we are testing software that has already been tested and known to be working? Not really, since there is the potential that defects are lurking somewhere in already-tested software. Remember the principle that testing can show defects are present, but cannot prove there are no defects. Even if we consider a piece of software thoroughly tested, that does not mean it has been completely tested and free of defects (another principle to remember - exhaustive testing is impossible).

If your company is not using a regression suite, the time to consider creating one is now! It is important to gather test cases that cover a broad expanse of software functionality, focusing on high-risk and high-priority areas that are central to user acceptance. The suite should consist of a large number of high-level tests that are linked with your company's goals and expectations of how the software should behave. It would also be wise to include tests that concentrate on known problem areas of the software where defects have clustered in the past.

Regression test suites should be reviewed regularly to surmount the Pesticide Paradox (yes, another testing principle!). The Pesticide Paradox explains that if the same test cases are repeated over and over again, then these test cases will become more unable to find new bugs and defects over the course of time. Think of new scenarios to test existing functionality and incorporate these fresh test cases into the regression test suite. Crafting these scenarios allows you to think of creative strategies to test the software and hopefully find defects that would have otherwise gone unnoticed, and alleviates any boredom that may arise from repeating the same tasks.

It is often the case that regression suites take a lengthy amount of time to run, so look into the possibility of automating portions of the suite. Test automation works best on stable areas of the application, so automating regression tests will save a significant amount of time in the long term and provide an efficient method of testing portions of the software.

Does your company need help with creation, maintenance, and/or automation of a regression suite? DeRisk IT Inc. has experienced, onshore software testers to help you with all of these quality assurance needs and more. You can contact us here or give us a call at 205-487-8793 for any questions about our services.