Lesson 4 of 5
Traceability and evidence
8 min
Listen to this lesson
A closed defect is a claim: "this problem was found, fixed and verified". Traceability is what makes the claim checkable. Every defect should link back to where it was found (the test run and test case), to what it threatened (the requirement or process step) and forward to how it was fixed (the transport or deployment item) and how the fix was verified (the retest run). This chain is what makes a sign-off defensible to a process owner, an auditor or your successor.
Backward links: where and why
Linking a defect to its failed test run records the context: system, client, build, data and evidence. Linking to the test case and its requirement records the business stake: which requirement is unproven while the defect is open. In SAP Cloud ALM, a defect raised from a failed test action is linked to that test case automatically, and defects can also carry the related process hierarchy node. That lets the test lead answer "which requirements are at risk?" by listing open defects by requirement or process.
Forward links: how it was fixed
The fix is code or configuration that moves through the landscape in a transport. Recording the transport number on the defect lets anyone confirm three things: the fix was imported into QAS before the retest, the same transport is in the release going to production, and no unrelated change rode along unnoticed. In SAP Cloud ALM, changes are typically organized as features that carry their transports through the landscape, so a defect can be linked to the feature that resolves it. Programs using SAP Solution Manager have similar change-control links.
- Day 1Fix built in DEVConsultant corrects revenue account determination and releases the transport
- Day 1Number recordedTransport number entered on the defect
- Day 2Imported into QASImport into client 100 confirmed; defect moves to ready for retest
- Day 2Retest passedTester re-runs the failed case and attaches the passed run
- ReleaseIn the release listThe same transport is confirmed in the release going to production
Fixes that do not travel in a transport need the same discipline. A master data correction, a condition record change or a fix in a partner system is still a fix. Record what was changed, by whom, in which system, and how it will reach production, whether by a data load, a manual step in the cutover plan or the partner's own release. Otherwise the defect passes retest in QAS and returns in production because the data correction was never repeated there.
| Aspect | Fix in a transport | Fix outside the transport path |
|---|---|---|
| Examples | Configuration or code change | Master data correction, condition record change, partner system fix |
| What to record | Transport number and import date in QAS | What was changed, by whom, and in which system |
| How it reaches production | With the release, automatically | Data load, a manual step in the cutover plan, or the partner's release |
| Risk if not recorded | Fix tested in a different build than goes live | Passes in QAS, then fails again in production |
| Question at sign-off | Answered by the link |
|---|---|
| Which requirements are not yet proven? | Open defects → test cases → requirements |
| Was the fix tested in the build that will go live? | Defect → transport → import history in QAS and release list |
| Did anyone check the fix did not break something else? | Defect → regression runs linked after the fix |
| Who accepted the risk of a deferred defect? | Defect → deferral reason, approver and target date |
Traceability turns sign-off questions into lookups.
What auditors look for
For processes with financial reporting impact, external and internal auditors often review whether changes to the system were tested and approved before reaching production. A complete defect record, with evidence of the failure, the approved fix, the transport and the passed retest, is exactly the kind of evidence that satisfies them. A defect closed with "fixed" and nothing attached is the kind that generates audit findings.
The easiest way to keep the chain intact is to make it part of the workflow rather than a cleanup task at the end. Raise defects from the failed test step so the link exists from the start, require the transport number before a defect can move to ready for retest, and retest from the same test case so the passed run attaches itself. Then the evidence pack for sign-off is mostly a report, not a week of archaeology.
What would you do?
During Contoso's sign-off review, Dan finds a closed high-severity defect on fleet revenue with only the comment "fixed by consultant". No retest run or transport is linked. What should he do?
- Link each defect back to the test run, test case and requirement it affects.
- Link it forward to the fix transport or feature and the retest run.
- The transport number proves the fix was in QAS for the retest and is in the release.
- Auditors expect evidence of failure, approved fix and passed retest.
- A closed defect without the chain is unproven.
Check your understanding · not graded
Lesson check
1. Why link a defect to the requirement behind its test case?
2. What does recording the fix transport on a defect allow?
3. In SAP Cloud ALM, what happens when a defect is raised from a failed test action?
4. A closed defect has no retest evidence. How should it be treated at sign-off?