Regression Testing
Introduction
Changes are typically made to a software to either enhance it by adding a new feature or to fix it by removing a bug. This arrives to the end user in the form of software updates that hopefully make our lives a bit better by making the software even more useful. However, sometimes the changes made to the underlying code can have unintended side-effects. If our software does not perform as expected after the changes that is called a regression. So how can we prevent regressions in our software? One of the most effective ways is to do regression testing.
The Concept of Regression Testing
Regression testing is one of the simplest and most useful concepts in software testing. It is simply the re-running of tests to ensure that our software still works as expected after changes to the code. So how is this different from simply confirming that our changes work as expected?
Confirmation Testing
Confirmation testing confirms that an original defect has been successfully fixed. Depending on the risk, one can test the fixed version of the software in several ways, including executing all test cases that previously have failed due to the defect, or, also by adding new tests to cover any changes that were needed to fix the defect.
However, when time or money is short when fixing defects, confirmation testing might be restricted to simply exercising the steps that should reproduce the failure caused by the defect and checking that the failure does not occur.
Why Do Regression Testing?
Regression testing confirms that no adverse consequences have been caused by a change, including a fix that has already been confirmation tested. These adverse consequences could affect the same component where the change was made, other components in the same system, or even other connected systems. It is still advisable first to perform an impact analysis to optimize the extent of the regression testing, since usually there is not enough resource or time to simple retest every aspect of the software before a new release. Impact analysis shows which parts of the software could be affected, but regression testing can and should include the execution of previous tests that seem unrelated to the changes. It might sound surprising but in practice regularly re-running test cases of important areas usually results in finding bugs that otherwise would have gone unnoticed into production and even just developing complex regression test cases can prove valuable as an experienced QA Engineer might catches a lot of bugs even after a feature was acceptance tested by someone.
Automating Regression Tests
Regression test suites are run many times and generally the number of regression test cases will increase with each iteration or release to cover for the additional functionality, so regression testing is a strong candidate for automation. Automation of these tests should start early in the project. Where CI is used, such as in DevOps, it is good practice to also include automated regression tests. Depending on the situation, this may include regression tests on different levels.
Confirmation testing and regression testing for the test object are needed on all test levels if defects are fixed and or changes are made on these test levels.
Summary
Regression testing might sound trivial at first but as software typically get ever more complex one must develop the right strategy to execute the most important testing cases with the given resources.
At Fuserwise we have all the testing competencies available for your needs, if it is developing the strategy and the test suit base for your project in the first few months by an experienced Test Manager and then switching to a Manual Tester, you have the flexibility to only you the exact resources you need at any time, without the need for training or hiring.
