Lesson 5 of 5
Evidence trails
9 min
Listen to this lesson
Sign-off is a claim: "this release does what it should, and we can show it." An evidence trail is what lets someone else check that claim later: an auditor, a new release manager, or the team itself during an incident. Architects decide whether evidence is a by-product of normal work or a scramble of screenshots at the end of each cycle.
The chain of evidence
- RequirementWhat the business needs, with acceptance criteria and risk
- Design and buildConfiguration and code, recorded in transports linked to the requirement
- TestTest cases linked to the requirement; runs with results, data and logs
- DefectsFailures recorded, fixed in linked transports, retested
- DeploymentTransports imported to CMP after approval, with dates and approvers
- OperationChange documents, application logs and monitoring show the live behavior
SAP Cloud ALM supports much of this chain for the S/4HANA program: test cases built from solution processes, test plans with their own execution context, test runs and defects created from failed steps, and traceability that links test cases to requirements and user stories to show coverage. The architecture decision is to use these links consistently, so that the chain exists without extra effort, rather than keeping test evidence in spreadsheets and email.
Evidence the system produces
| Source | What it proves | Design decision |
|---|---|---|
| Transport logs | What changed, when, imported by whom | Every change goes through transports linked to a requirement or defect |
| Change documents | Who changed a master record or document field and when | Confirm change document logging for custom fields that matter |
| Application logs | What a process did, with business keys | Log key steps of custom processes with message IDs |
| Test runs and results | What was tested, with which data and outcome | Automated tests write document numbers and compared values |
| Monitoring data | Interface and job outcomes in operation | Business context attributes and retention set by design |
System-generated evidence and the architecture decisions that make it usable.
Designing tests to produce evidence
Automated and manual tests should leave evidence that a reviewer can check against the system: the document numbers created, the values compared, the messages accepted and the system, client and build used. Screenshots are useful at decisive points, but a log of numbers and values is easier to verify and to search. For regulated processes or audit-relevant controls, decide in advance what evidence each test must keep, for how long, and where; the regulated validation course goes deeper into those requirements.
- DesignEvidence planWhich tests are audit-relevant; what they must record; retention
- BuildEvidence hooksLogs with business keys; tests that capture numbers and values
- Test cyclesEvidence capturedRuns, results and defects linked in SAP Cloud ALM
- Go/no-goEvidence reviewedCoverage by risk, open defects, reconciliation results
- After go-liveEvidence retainedAvailable for audits and incident analysis
Evidence that stays trustworthy
Evidence is only worth something if nobody can quietly change it later. Test results should be locked once a run is complete; corrections are made by a new run, not by editing the old one. Transports, change documents and application logs are written by the system, which is exactly why they carry weight. Agree retention with the audit and compliance owners: how long test evidence, logs and defect records are kept, and where. A trail that is deleted before the next audit is no trail at all.
What would you do?
An auditor asks Contoso how it knows that the purchase order approval threshold of $25,000 was tested before go-live. Which answer shows a good evidence trail?
- Evidence trails link requirement, change, test, defect, deployment and operation.
- Use SAP Cloud ALM links consistently so evidence is a by-product, not a project.
- Design system evidence: transports, change documents, application logs, monitoring.
- Tests record numbers, values, messages and build; plan retention for audit-relevant tests.
Check your understanding · not graded
Lesson check
1. What makes an evidence trail useful?
2. Which SAP Cloud ALM feature shows coverage by linking test cases to requirements?
3. Which system record proves who changed a master data field and when?
4. What is a quick way for a process owner to test an evidence trail?