There are various forms of testing that are done on a fixed code. The confirmation testing helps to verify the fixes that have been implemented. The other kind of testing is the regression testing, which checks that the fix hasn’t disturbed any existing functionality. The same can be used when a new functionality gets added to an existing application.
Over the time, as more components like functionality gets added, the software application becomes bigger. With the release of each new version of the application, a set of test cases (Regression test) is developed to be run. Most of the organizations prefer to perform a full regression test each and every time a new patch is completed.
A tester can’t deny to regression testing being a necessary endeavor; however, at the same time it’s very time-consuming. But, the question is how much regression is really required?
This question is quite tricky, as it is difficult to know when you do and when you don’t. In any way the answer to this question is not so easy. Moreover, you might get contrasting answers from different testers based on their experience and skill set. In my opinion, the answer lies in the application being tested, the bug that has been fixed, and the time since you have performed the last regression test.
If the application being tested doesn’t involve too many complications and moving parts, then a full regression test isn’t required too often. However, there are situations where you might require running full regression more often. Some of them are mentioned below.
- In case of a highly complicated application
- An application requiring more calculations
- If an application depends on input from multiple sources
- In case of a high-end or secured application
In addition, you must not miss considering the bug or patch that has been fixed. Some of the aspects that might prove helpful in deciding the necessity of regression testing are mentioned below.
- How many different parts of the application are related to the patch?
- How many pages and modules were covered?
For these kinds of queries, developers are the right people to answer, as they are the ones who did the work. By asking them such questions, you can get to know the changes that have been made.
- Did they touch a saved procedure that is used in the entire application?
- Was the modification just on a single page or a single line of code?
Understanding the depth of changes is significant; as it helps you decide if a full regression is required or not.
The time since last full regression is yet another important consideration. You can go for a full regression if you have been practicing focused regressions after each patch for months. Scheduling full regressions every month or quarter on a regular basis is one of the best practices in the software industry. By scheduling regressions, you can ensure a bug free application and save a lot of time, which is otherwise wasted during full regressions for every single code change.
However, you can consider performing regression tests at any other point. This can be performed irrespective of the number or types of patches done.
