2.5 Confirmation, Regression, and Maintenance Testing
Key Takeaways
- Confirmation testing checks whether a specific defect fix has resolved the reported problem.
- Regression testing checks whether unchanged parts of the system were adversely affected by a change.
- Maintenance testing is triggered by modifications, migration, retirement, or changed environments.
- Impact analysis helps decide what to test after a change.
- Automation is often valuable for regression testing, but test selection still requires risk judgment.
Testing After Change
Software changes constantly. Defects are fixed, features are added, platforms are upgraded, data is migrated, interfaces change, and old systems are retired. Each change can solve one problem while creating another. That is why confirmation, regression, and maintenance testing matter.
Confirmation testing, sometimes called retesting, checks whether a specific defect fix worked. If a defect report says the checkout total ignored gift cards, confirmation testing repeats the relevant scenario after the fix and checks whether the gift card is now applied correctly.
Regression testing has a different goal. It checks whether unchanged parts of the system still work after a change. The gift card fix might accidentally affect discounts, tax calculation, invoice generation, or refund processing. Regression testing looks for unintended side effects.
| Testing activity | Main question |
|---|---|
| Confirmation testing | Did this specific fix resolve the reported defect? |
| Regression testing | Did the change break behavior that should still work? |
| Maintenance testing | What testing is needed because the system or environment changed? |
| Impact analysis | Which areas may be affected and should be tested? |
Maintenance testing happens after release when the software is modified, migrated, retired, or affected by environmental changes. A database upgrade, browser change, operating system patch, cloud service change, or business rule update can trigger maintenance testing even if users do not see a new feature.
Impact analysis is the study of what may be affected by a proposed or completed change. It helps select regression tests, identify affected requirements, estimate effort, and reduce the chance of missing a side effect. Traceability improves impact analysis because it links requirements, code, tests, defects, and results.
Regression suites often benefit from automation because they are run repeatedly. However, automation does not decide what matters. A stale automated suite may miss the new risk created by a change. Testers still need to review the change, the affected architecture, defect history, and business impact.
A common exam trap is to call every test after a fix regression testing. If the test checks the exact defect that was fixed, it is confirmation testing. If the test checks other areas for unintended side effects, it is regression testing. Both may be necessary.
Another trap is to think maintenance testing means only bug fixes. Maintenance includes planned enhancements, emergency fixes, migration to a new platform, data conversion, and retirement of functions. The test objective depends on the trigger and risk.
When answering CTFL questions, look for the target. Specific defect fixed equals confirmation. Unchanged functionality affected by a change equals regression. Released system changed or environment changed equals maintenance. Analysis of affected areas equals impact analysis.
After a developer fixes a reported login defect, a tester repeats the failing login scenario to see whether it now passes. What is this called?
Which situations can trigger maintenance testing?
Select all that apply