Sometimes software changes require multiple rounds of testing, and we often refer to this process as “retesting”, especially if the retest relates to a particular bug fix.
Retesting can also take place when the developer rejects a bug because they believe the software is working as expected, and the tester needs to repeat the specific test.
As a tester, when you’re retesting software changes, you’ll need to repeat a full test run or repeat a selection of test cases that failed and have subsequently been fixed by the developer.
Why is retesting important?
In our earlier blog, What is Software Testing, and How Does it Work?, we explained that the aim of software testing is to identify and fix bugs. Retesting is an important element of the overall software testing process and should form part of your test strategy.
Let’s face it, we’re only human, and even the best developers make honest mistakes. This principle applies when implementing new functionality and fixing bugs found during testing.
It’s normal in software development for one process to impact another, and a developer may not consider dependencies when fixing a bug relating to a specific, failed unit test.
We all agree that we wouldn’t release software to a customer or the business without completing at least one round of testing, so it makes sense to retest after fixing bugs.
Why should I repeat a full peer test run when retesting software?
Your test strategy should determine when you need to only repeat failed tests when retesting software and when a full repeat test run is needed.
For example, you may set a threshold for the percentage of tests that need to pass during the first test run to justify only repeating failed tests. This approach assumes the fixes haven’t broken any of the tests that passed previously, which introduces risk but also saves time.
In Qucate, our test management platform, you’ll be able to identify trends and track your functional software testing, so you’ll have an overview of how many tests have passed or failed.
Alternatively, you may want your developers to repeat the entire test run every time. Although this approach takes longer, it will also help you to find any new bugs that have been introduced. After all, there’s no such thing as too much testing, right?
Retesting and regression testing
It’s important to understand the difference between a retest in software testing and regression testing.
Retesting does not replace regression testing, as it focusses on repeating failed unit tests. Whereas regression testing checks if a new feature breaks existing core functionality and should be carried out before every release.
Qucate
If you’re looking for a test management platform to help with retesting, Qucate uses dynamic test run templates to speed up the process and improve the quality of your software.
Head to our Qucate page for more information, or feel free to contact us.
