Retesting also known as Confirmation Testing is a software testing in which the software is tested again to check whether the good test cases which failed earlier is now working when the bugs and errors are fixed in the software.
This testing is done for the assurance that, after the removal of bugs and errors from the software and after fixing all the missing functionalities, the software is able to execute the test cases and produce positive results.
Retesting is carried out after any kind of changes made to the system. This testing can ensure that the software has no defect after the bugs have been fixed and is ready for integration or system testing.
Retesting looks somewhat similar to regression testing. But they are totally different. Regression testing is done to see whether the addition of new codes, functionality or features has hampered normal functioning of the software or has induced any kind of bugs.
On the other hand, Retesting is done to check whether the system is performing well after the bugs and errors have been fixed or corrected. Both the testing has a very different aspect. We shall see the difference in more details.
There are infinite reasons why to carry out retesting. Below we shall see the major reasons for retesting:
When good test cases are applied to the software and errors are found, it is assumed that the problem is inside the software. Now the bugs and broken modules inside the software is fixed and then the same test case in the same environment is applied to the software.
This process continues until the test cases are fully accepted by the software and the desired result is produced. Therefore, in the end, it can be confirmed that the software has no more errors handling the test cases.
The errors and bugs can be fixed, but if not checked and left for the integration test phase, then the entire process can be compromised.
Let us consider, a scenario that, there is a module in a software which accepts a data and checks it's datatype. It accepts only if is an integer. Now let us say, the module is diagnosed with an error, and the developer was confident enough that they have found out the problem.
So, they have fixed it with their expertise and did not want to test it separately, as they were confident enough that they have diagnosed the issue and it has been corrected.
Now, when the modules are integrated one by one, and when an integration testing is performed, the entire output fails. Now the developers are confused which modules have caused the error. Left with no other option, they have backtrack.
And unfortunately, the problem was in the same module which they fixed but did not check. Since, its data was pipelined to different modules, so created different types of errors in the software.
In this example, we have learned that how effort is maximized when Retesting was ignored.
Many companies are there who are interested in Bussiness Process Outsourcing. That is, they send all their tested modules to some other companies for integration testing. Now if there are always bugs reported in the modules itself, which are the results of lack in retesting, the reputation of the company will vanish.
The practice of Retesting a module before it is left for integration testing should be followed by each and every developer of the company belonging to the low as well as the top levels.
Retesting is mainly aimed at checking the smaller parts of the software. The small parts could be small modules. Therefore, when retesting is performed at a smaller level of the software, it becomes very much easier for the tester or developer to troubleshoot the entity causing the error.
When modules or units are integrated than the chances of finding the error lessen. This is one of the reason that after all the bugs are fixed, retesting should be carried out, which could save time and effort in retesting the integrated module. Small is better.
Retesting raises the standard of the software, as test cases are made for each of the parts of the system. Therefore, all the individual modules can be check with different test cases which helps in making the software better.
In the phase of retesting the software is tested again and again until the bugs are fixed. In this process, the bugs are fixed and at the same time, the rest of the code also gets a chance to be tested and optimized if possible.
There is no thumb rule set for retesting a software. Different companies ranging from small to large have different formats of Retesting. Below we shall see a very typical way of Retesting:
The first step is to apply the GOOD test case into the software module or the software. The actual result is then compared to the expected output of the test case. As we said, we apply good test cases which means that the test case already has a formatted standard pre-executed result sheet.
When the software fails against the test case, it cannot be directly tracked which module has created the error, and nearly impossible, if the software is a complicated one. Therefore, the software part is broken into individual modules and then small test cases are applied for the individual modules.
And therefore, the module which is not making the result as expected, are considered as defective modules. In this way, the defective module is tracked out.
Apply Retesting into the defective module until it is fixed.
After the modules which are defective are fixed, the test case for the whole integration can now be applied into the software and then it is checked whether the software is working fine.