Lesson 5 of 6
Retest and regression
8 min
A defect is not finished when a developer says it is fixed. It is finished when a tester has proved the fix in the test system and checked that nothing nearby broke. This lesson covers that last mile: the defect lifecycle, retesting, regression checks and when to reopen.
- NewTester raises the defect with steps, data and evidence
- In processTriage sets priority and assigns a fixer, who analyzes and corrects
- Ready for retestThe fix is in a transport or configuration change that has reached the test system
- RetestThe original tester (or a delegate) repeats the failed steps
- Closed or reopenedPass → close with evidence · Still failing → reopen with new evidence
Before you retest
Check that the fix has actually arrived. Most "the fix doesn't work" reports on SAP projects are fixes that are still in the development system. The defect should name the transport request or configuration change; your test lead or the transport log can confirm it was imported into your test client. Also check your data: if the original order was created with wrong prices, the fix may only affect new orders. Retest with fresh data unless the defect is about correcting existing documents. Finally, retest as the right user. If the fix was an authorization change, only a user with the corrected business role proves it; a tester whose role already worked proves nothing. Agree with the test lead who retests: usually the person who found the defect, because they know exactly what they saw, with a delegate named for absences so fixes do not queue up waiting for one person.
What to retest
First, repeat the exact steps that failed, with the same kind of data, and compare with the original expected result. Then go one step wider. A pricing fix can change the order value, which changes billing, which changes revenue and tax postings. Run the downstream steps of the scenario, not just the step that failed. Finally, consider siblings: if the fix changed a condition record or a shared configuration table, ask the fixer what else uses it and run a quick check of those scenarios too. That is regression on a small scale: proving the change did not break what used to work.
| Retest scope | Contoso pricing fix example | Why |
|---|---|---|
| The failed step | Create order for 50 CMC-ALT-100 for Great Lakes Fleet Services; price 150.00 | Proves the fix |
| Downstream steps | Delivery, goods issue, billing; check billing price and revenue journal entry | The changed value flows on |
| Sibling scenarios | Aftermarket customer order with the same product; plant 1720 order at the Chicago price | Same configuration, different paths |
| Unchanged scenarios at risk | A standard order with a manual discount | Shared pricing logic |
Reopen or raise new?
- Does the original problem still occur with the original steps?Yes → reopen the defect with new evidence and the build tested · No → continue
- Is there a new, different problem caused by the fix?Yes → raise a new defect and link it to the original · No → continue
- Do the downstream and sibling checks pass?Yes → close the original defect with retest evidence · No → raise new defects for each distinct problem
What would you do?
Maria retests the pricing defect. The order now shows 150.00, but the billing document still bills 165.00. What should she do?
- Confirm the fix has been imported into your test client before retesting.
- Retest the failed steps, then downstream steps, then sibling scenarios.
- Reopen if the original problem remains; raise a linked new defect for a different problem.
- Close defects with evidence of the retest, including the build tested.
Check your understanding · not graded
Lesson check
1. What should you check before retesting a fix?
2. The original defect is still reproducible after the fix. What do you do?
3. Why run downstream steps after a pricing fix?
4. What is regression in this context?