Testing is an ever-present part of a software developer’s job, performed at every stage of the production process. There is a wide range of test types used for software testing, some performed at various points during production, and some performed after production to confirm that the software functions as intended.
Regression testing is performed on a product that has already been finished and released. How exactly is it performed? What are the objectives and how does the procedure look? If you’re keen to find out, keep on reading as we explain everything you should know about regression testing.
Regression testing is a software testing method that aims to investigate and locate any possible flaws or bugs in software that has already been fully developed. Regression Testing is performed to find out whether your software has regressed (surprise, surprise) as you continue introducing new updates and bug fixes. Whenever a piece of software is changed in any way, new bugs might emerge and some of the older ones re-emerge.
Most often, regression testing is performed immediately after introducing a new update, but it isn’t the only factor that might call for the test. If any software or hardware-related factor has changed, regression testing should be committed to find out whether everything performs as it has before the change. This can include any sort of bug fixes and software changes, but regression might also be caused by hardware configuration changes and electronic component degradation over time. Regression testing isn’t easy – it requires cooperation and diligence out of all of the team members, which makes it perfect for Agile Software Development practices.
Regression testing can include various functional and non-functional tests in its process to thoroughly investigate the software in search of flaws. There are also many techniques with which developers and QA specialists perform regression testing, including:
The Retest All technique is the most accurate and all-around method of regression testing, but it is also the most expensive one. In Retest All, every test case is checked again on the software to confirm if all of its parts are working as intended. That’s all there is to Retest All – it might be simple in definition, but it is definitely the hardest and most costly technique to actually perform.
Regression Test Selection has been designed as a solution to the expensive nature of the Retest All technique. In RTS we don’t run all of the tests in our test suite, but instead we divide all of the tests into three categories – reusable test cases, retestable test cases, and obsolete test cases. In addition, RTS might actually create new test cases that haven’t been in the suite before, but might be relevant for regression tests.
If you’re interested in finding out more about regression testing examples, we recommend taking a look at Understanding Regression Testing Techniques by Gaurav Duggal and Bharti Suri. The authors further divide RTS techniques, naming two most important categories – coverage techniques and minimization techniques, and explain what are safe techniques.
Coverage techniques feature specific coverage criteria, often provided by the client who wants their software regression tested. These techniques sift through all test cases, selecting only the ones that are relevant for the covered parts of your software. Minimization techniques work in a way similar to coverage techniques, but instead of selecting cases based on set criteria, you select a minimum set of cases that you think will do the job.
Test Case Prioritization aims to maximize the rate of fault detection, creating the most thorough regression test for the lowest cost. Every test case is assigned a priority, after which all of them are performed in order, starting from the most important one and finishing on the least important one. Thanks to that, even if your resources aren’t enough to perform all of the tests in your suite, you will still perform the ones that should detect the most flaws.
TSP might be performed in two ways – the first one, called General Prioritization, selects test cases that should be effective (on average) on all versions of the software you’re working with. The other way, called Version Specific Prioritization, only takes into account a specific version of the software, without considering other existing or potential future versions.
When choosing one technique of regression testing is impossible – why not combine the best features of Regression Test Selection and Test Case Prioritization? The hybrid approach is still being developed, and every researcher gives a personal spin on the idea. Since there isn’t an exact definition of what a hybrid approach actually is, there are tons of versions available – each one with its own upsides and downsides.
As you have already learned, regression tests are performed to keep the quality of your software as high as possible for as long as possible. Updates and changes to your software might introduce new problems, which is exactly why regression testing is so important – to keep user experience high throughout all iterations of your program.
Not all projects require regression testing, of course. In projects that are already finished and won’t be further updated, regression testing is mostly irrelevant. However, if you are planning to continue development further – never forget to properly regression test your software before releasing an update.