The Difference Between Regression and Retesting

As you become familiar with software testing, you may be getting a sense of the different types of testing that exists. Two types of testing, namely regression testing and retesting, often become confused since they occur after development. However they are quite different.

The difference lies in their respective objectives and priorities. The easiest difference to identify is testing where bugs previously existed vs. where none existed. Retesting specifically tests scenarios if a bug that previously existed has been fixed, and regression tests check for whether new bugs have appeared. 

Let’s go over each of these separately to explain the differences. 

When to use Re-testing

Test defect fixes

Retesting refers specifically to testing software after fixing defects (where application behavior varies from business requirements) or bugs (flaws in code). It is designed to determine whether software works where it previously did not. 

Retesting cannot be automated

Test cases are specific to bugs, and not for working states. Retesting exists purely to execute test cases where the software had failed previously. This is one of the reasons why we sometimes state that manual testing cannot be completely replaced; at some level, you will need to retest your code after fixing a bug. Typically, this is handled by the developer as defects are fixed.

Retesting is a planned process

Retesting occurs after a defect has been fixed; it is designed to check whether defects have been fixed. To pass a retest, an application must go through a checklist of items that had failed in previous circumstances. Retesting is also known as “planned” testing, or “confirmation testing”

High Priority

Retesting has a higher priority than regression testing, meaning that retesting is carried out before testing process. 

Discrete

Retesting is discrete; it only occurs in the specific area where the defect or bug previously existed.

When to use Regression Testing

Tests for Regression

Regression testing is a test of software to make sure that fixes to bugs do not create new ones in other parts of the app. It ensures that the code has not “regressed” to a non-working state.

Test for unintended consequences

Regression testing is designed to determine whether software continues to work where it previously had after another part of the application has been modified. In other words, it tests to make sure that software that had previously passed testing continues to do so after a defect has been remedied.

Not for Defect Testing

Regression testing does not test for defects, or variations from business logic. It is not designed to focus on specific bug fixes but is planned for tests of areas of an application or the full application at given times. Regression testing does, however test for unexpected side-effects of defect fixes.

Broad-based Testing

Unlike retesting, regression testing is not discrete; it is a broad-based form of testing to check the rest of an application after fixes to bugs or defects. It is broader by necessity. 

Another word for regression testing is “generic testing.” Tests can be constructed based on functional requirements. In other words, it is a generic test of software to ensure that it works and continues to work. It is generic in that it is not discrete; it is generalized testing across an application with the goal of identifying any previously undetected (or uncovered) bugs or defects.

Lower Priority

While typically done after retesting, regression tests and retesting can be done simultaneously.

While retesting is for ensuring that specific defects have been remedied, regression testing identifies newly introduced bugs or previously unidentified flaws in the system.

Automation

Regression testing can be fully automated – test cases expand with each new build or change, but these test cases can be included as modules within a larger test. 

Regression tests can be automated at the lower code level with unit and integration tests, and at higher levels, with systems and end-to-end tests. Regression testing tools like mabl were built to make end-to-end regression testing easy. mabl in particular uses machine learning to identify visual and performance regressions automatically under the covers as your functional tests run.

Conclusion

In case you have any lingering confusion, it may be easier to think of retesting as checking to see whether you actually fixed a bug and regression testing as whether you created any new bugs with your fix. While you may identify regression problems during a retest, they are in fact separate and should be treated as distinct forms of testing.