Sunday, January 6, 2013

Regression Testing

Can someone tell whether the last bug is removed from the product? Can someone give 100.00% guarantee that the testing is fully done? Yes and No. Given the time, it can be done; but then what is the timeframe one needs to get to this level? Karate Schools believe in repeating certain exercises to attain perfection. Practice leads to perfection. Practice is nothing but doing it again and again, and ever improving. This holds good for software testing also.

When we walk thru the regular SDLC, the system testing happens once the product is given to the QA team. A set of bugs are published and those bugs get fixed by the development team. What next? Again testing  happens. The question is , how much testing must happen again? Well, the ideal goal is to do all tests on the product once again. This will ensure that a fix in one place does not break something else. But, do we have people, time and money to do all tests again? The following principles are used in most of the organization when it comes to repeating tests. 

Whatever tests we did in build 1, that have passed in build 1, must not fail in build 2. This is fundamental. So ideally we must execute all test cases in build 1 and 2. Assume that there are 500 tests and we executed all of them in build 1 and around 60 test cases failed. When build 2 comes, the first priority goes to checking those failed test cases for the correctness of the fix. This is called re-testing. That means, a test case failed and it was fixed and we execute that test case again. Forgetting all other tests, we check this test case alone; this is re-testing. To find out whether there are any side effects due to the fix, we must do regression tests. Regression testing means, to re-test the test cases that have passed in previous build also. Every time you go to the doctor, the doctor checks the pulse, temperature etc. That part is regression. Same way we must repeat passed tests also, to ensure functional stability.

But how much regression is good? A few simple principles you may try. These are some generic thumb-rules used by most of the companies.
  • If a test case fails for a field, repeat all test cases for that field.
  • If a test case fails for a screen, repeat all test cases for that screen.
  • If a test case fails for a data entity (e.g. purchase order, Invoice etc.), repeat all test cases for that data entity wherever that is used.
  • If a test case fails for a functional module, repeat all test cases for that module.
You are the ultimate authority to decide which suits better for your product within the timeframe you have got. If you are able to cover up a larger area of the application, around the failed test cases, your chances of blocking all loopholes is high.

When it comes to large products such as ERP, when the product reaches the system testing phase, the work of developer may be just 10 minutes to fix a bug; but the testing will go on for days, due to regression. Hence, testing takes a huge effort build after build. You can ask me whether companies are doing proper regression testing. The answer I can give is that those companies that do proper regression have stable products  and larger customer base; this is due to the quality of the product being tested again and again.

For a free test management tool, visit

For free recorded training, visit



  1. Understanding the requirement of test tools is the first step of selection. The project managers and Test Management Services the team leaders must review the needs and then consider selecting tools. In other words the business must understand what exactly they are looking for and the selection procedure must be based on those findings.

  2. Hi,

    Really it is very useful for tester to understand for Re-Test and Regression Testing. I found this article for more examples, so this will be easy to understand by the user.