Table of Contents
- The definition of Regression Testing
- Regression Testing process
- Regression Testing techniques
- Regression Testing tools
- Disadvantages of regression testing
- Conclusion – is Regression Testing necessary?
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.
The definition of 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.
Check also our guide on Regression Testing in Agile.
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 process
As with most testing efforts regression testing is an art rather than science. Let us describe the regression testing process that our development team uses. You may then use and adapt it to your existing test strategy.
Identify code changes
This will allow you to asses the number of test cases for regression testing that will need to be created. The testing team will need information on the impact that the current changes may have on the whole application. This is done also during this step.
You finished step one with a list. Now you need to create a queue out of it. By proper prioritizing the changes in your software application you reduce the amount of time you will use on
Select for re-run
This is the part where the selection of test cases is performed. After the first test is done, test cases are categorized into reusable and obsolete ones. The reusable ones create a regression test suite. The others are will not be used for regression.
Categorize manual and automated regression test cases
Here is where the test automation actually begins. Test cases that occur more often within one process are perfect candidates to for the automation tool to do the work for you. If you want to automate tests in a fast and efficient way, try BugBug as your tool for regression testing. You will soon find out that it is great to reduce regression testing costs.
Prioritize test cases
Here is where regression testing becomes a tad tricky. One would think, that the most often occurring test cases should have the biggest priority, right? Well the theory on that one is a tad different. The need for regression testing, therefor the priority, is the highest for those cases, that cover all essential features. The lowest on the other hand are stated as "technical complexities".
Plan and execute
This one is rather obvious, but we have to put it here. After doing all the analysis, you have to plan when regression testing is done and "push the execute button".
Regression Testing techniques
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:
- Retest All
- Regression Test Selection
- Test Case Prioritization
- Hybrid approach
Retest All – an accurate yet expensive solution
**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 – when you realize you might not have enough for a Retest All
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 – a rational approach
Test Case Prioritization aims to maximize the rate of fault detection, creating the most thorough regression test for the lowest cost. First you prioritize the test cases one by one. Then 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.
Hybrid approach – the best of both worlds
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.
Regression Testing tools
Regression testing ensures that each version of your software runs smoothly. We have described various regression testing techniques, but our article would not be complete without a few hints of what tool to use for proper test execution.
Regression testing is used on an incremented basis. Each release of your software means building another layer of an already high pile of multiple regression test cases. A good tool will allow you to perform regression tests without writing a single line of code.
Check also 5 Best Regression Testing Tools.
Disadvantages of regression testing
Well now that's a shocker isn't it? We have many articles on testing in the BugBug blog, and never have I ever wrote anything negative about testing. Until now. We found four "buts" on regression testing and we tried to tackle them immediately.
- "but regression testing is time consuming" - yes, but only if you only perform a manual test, this is why selecting a good testing tool is essential
- "but you have to do it after even the smallest patch" - yes, but this is why you build a good regression cycle. You store all the recurring tests and only build a few on top of them for that given patch. It is like CI/CD for your testing process
- "but that process might interfere with the sprint planning" - only if you do regression tests without automation. Think of it from a business perspective - would you have a task that goes cross-sprint or a large bug in the production environment?
- "but it is difficult, to write those test cases" - ah, an oldie but a goodie. There are great no-code regression testing tools. Those might be used not only by QA or other technical personnel but by a PM. Such a person would be even able to automate the test or record and recreate it.
Regression testing is one of the key ways to have your code thoroughly checked and ready to start earning you money!
Conclusion – is Regression Testing necessary?
As you have already learned, regression testing plays a key role in keeping 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.
Happy (automated) testing!