Regression vs. Retesting

You must retest fixes to ensure that issues have been resolved before development can progress. So, retesting is the act of repeating a test to verify that a found defect has been correctly fixed.

Regression testing on the other hand is the act of repeating other tests in 'parallel' areas to ensure that the applied fix or a change of code has not introduced other errors or unexpected behaviour.

For example, if an error is detected in a particular file handling routine then it might be corrected by a simple change of code. If that code, however, is utilised in a number of different places throughout the software, the effects of such a change could be difficult to anticipate. What appears to be a minor detail could affect a separate module of code elsewhere in the program. A bug fix could in fact be introducing bugs elsewhere.

You would be surprised to learn how common this actually is. In empirical studies it has been estimated that up to 50% of bug fixes actually introduce additional errors in the code. Given this, it's a wonder that any software project makes its delivery on time.

Better QA processes will reduce this ratio but will never eliminate it. Programmers risk introducing casual errors every time they place their hands on the keyboard. An inadvertent slip of a key that replaces a full stop with a comma might not be detected for weeks but could have serious repercussions.

Regression testing attempts to mitigate this problem by assessing the ‘area of impact’ affected by a change or a bug fix to see if it has unintended consequences. It verifies known good behaviour after a change.

a) Retesting is carried out to verify defect fix / fixes. Regression testing is done to check if the defect fix / fixes have not impacted other functionality of the application that was working fine before applying the code changes.

b) Retesting is planned based for the defect fixes listed in Build Notes. Regression testing is generic and may not be always specific to any defect fix or code change and can be planned as regional or full regression testing.

c) Retesting involves executing test cases that were failed earlier and regression testing involves executing test cases that were passed earlier build i.e., functionality that was working in earlier builds.

d) Retesting will involve rerunning failed test cases that are associated with defect(s) fixes being verified. Regression testing does not involve verifying defect fix but only executing regression test cases.

e) Retesting always takes higher priority over Regression testing i.e., Regression testing is done after completing Retesting. In some projects where there are ample testing resources, Regression testing is carried out in parallel with regression testing.

f) Though Retesting and regression testing have different objectives and priorities, they equally important for project’s success.


Regression Testing: Testing an application after a bug is fixed. It is again of three types Unit regression testing Regional Regression Testing and Full Regression Testing.

Unit regression testing: Testing the application for the particular Bug fixed like the warning Messages pop ups etc fixing these will not affect the application

Regional Regression Testing: Testing a module for a bug fixed in the application. like suppose username field accepts “8-15 numbers” but requirements is changed to 10-20 “characters”. we will have to test whole Login module.

Full Regression Testing: Full Regression Testing is testing the whole application if a critical bug is fixed and has impact on various other modules. This also done before release to ensure application is working fine.

Re-testing: Testing the application again or re-executing the Test cases. Though after a release there remains no difference between Full regression testing and RE-Testing or we can say Once the bug is fixed the functionality needs to be tested to confirm that it is really fixed and this testing is called as retesting.