Should you retest closed defects during regression testing?

Should you retest closed defects during regression testing?

What are the benefits of retesting closed defects that are found during functional testing in the regression test phase?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Areas of code that need multiple fixes tend to be fragile. The value in retesting closed defects is that you are watching the code and application carefully to make sure an issue doesn't resurface, which is what regression testing is all about. There are instances where retesting all closed bugs becomes impractical.

Regression testing resources:
How to conduct regression tests

Regression testing: How to select test cases

Regression testing is more than retesting
What I've been doing on recent project work is not retesting the specific defect that was closed but opting to execute an exploratory test charter on and around that feature or functionality that had recent bug fixes. The point is twofold: first, to ensure that issues resolved haven't reopened, and the second is to provide a sanity check that the core functionality is working as expected.

I've been gaining more confidence in that approach, and when I think about why this may be more effective, it ties back to my first statement which is that areas of code that have needed multiple fixes are more fragile. With that potential in mind, a good test session in the area gives me more confidence than a one-off retest of a particular bug. I also think at some point, you have to consider the case closed -- meaning you have to begin looking elsewhere for bugs because by over-focusing in one area of an application, you could be missing defects in other areas of the application. I often remind myself to "keep hunting."

This was first published in November 2008