How should we Plan our Regression Tests – An overview
Primary aim of regression testing is to test the application due to changes made during a development spiral may be while debugging, maintenance, or even the development of a new release. In other words, we can say that the objective of regression testing is to minimize the cost of system revalidation.
The decision as to whether to go in for regression testing or not, depends upon the significance of the loss which could result due to improperly tested application. In other words, amount of regression testing depends upon the severity and impact of the fix applied.
Unless the regression testing process is automated by the use of some capture-playback tool it can be a very time-consuming and tedious.
When do we necessarily need regression testing?
Regression testing is carried out essentially under following situations:
1) When we make any functional improvements or carry out any sort of repairs to the system to ensure that the changes do not have any undesirable side effects.
2) When there is a high risk that new changes may affect unchanged areas of the application system.
3) When the potential loss that could occur due to affecting an unchanged portion is very high.
4) When following type of changes are made to the system:
# Corrections of errors relating to logic and control flow
# Corrections of computational errors
# Corrections of interface errors
We do not require regression testing after correcting cosmetic errors in the system, that generally do not affect other capabilities.
Typical strategies for regression testing can be:
1) Ideally all the tests in a test suite should be rerun for every new development spiral. However it may not be realistic due to time crunch.
2) Some regression testing should be carried out during every development spiral. This would ensure that previously proven capabilities are not adversely affected due to some correction of errors or by any of the later development spirals.
3) Regression testing must be treated as a subset of the system tests especially when the system is stable with verified functionality during the system testing. Test managers need to formulate policies to decide which tests to include.
4) Regression tests are the best candidates for test automation, especially when they get repeated time and again during every testing spiral.
5) Regression testing should be placed between the releases after the initial release of the application.
6) We should rerun every test after any correction, especially the ones that discovered an original defect.
7) We should try to exert deeply to ensure that the original defect had been corrected and not simply removal of its symptoms.
8) We should try to remove all the regression tests, which happen to repeat some other tests.
9) We should include all test cases in our regression test suite, especially the test cases in functional areas where some defect had been detected.
10) We must allocate a topmost priority & carry out thorough regression testing on defects reported by the client.
11) We can use retest matrix methodology to plan our regression tests, which works very well in relating the test cases to different functions or program units as described below.
Sr. | Business Function | Test Cases |
1 | 2 | 3 | 4 | 5 | ||
1 | Order Processing | |||||
a) Create New Order | � | � | � | � | ||
b) Fulfill Order | ||||||
c) Edit Order | ||||||
d) Delete Order | � | � | ||||
2 | Customer Processing | |||||
a) Create New Customer | ||||||
b) Edit Customer | ||||||
c) Delete Customer | � | |||||
3 | Financial Processing | |||||
a) Receive Customer Payment | � | � | � | |||
b) Deposit Payment | ||||||
c) Pay to Vendor | ||||||
d) Prepare a Cheque | � | � | � | � | � | |
e) Display Register | ||||||
4 | Inventory Processing | |||||
a) Acquire Vendor Products | ||||||
b) Maintain Stock | ||||||
c) Handle Back Orders | � | � | � | � | � | |
d) Audit Inventory | ||||||
e) Adjust Product Price | ||||||
5 | Reports | |||||
a) Create Order Report | ||||||
b) Create Account Receivables Report | � | � | � | � | � | |
c) Create Account Payables | ||||||
d) Create Inventory Report |
A tick mark in the retesting matrix means that we should retest the test case when the function or the program unit gets modified either due to some corrections or due to some enhancements. Blank or no entry indicates that we need not retest the subject test.
We can create a retest matrix even before the first testing spiral, but it needs to be maintained during subsequent spirals. As we modify the
How should we Plan our Regression Tests – An overview
functions or program units during a development spiral, new test cases may be created and checked into our retest matrix to prepare for the next testing spiral.
Over the passage of time with various spirals, we may find due stability in some functions or program units with no current modifications. In such situations, we may like to selectively remove their tick mark between different testing spirals.
Many More Articles on Test Planning & Management

An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.