Test evidence is maintained by keeping each execution result connected to the test case and step that produced it. A reviewer should be able to see the expected result, the actual result, execution status, supporting screenshots or notes where required, any linked defect, and the later retest or closure outcome. Evidence is useful when it is traceable and reviewable, not when it is simply a folder of screenshots.
Start with a defined test action and expected result
Evidence only has meaning when the test step is clear. Manual test cases should state what the tester must do and what result is expected. SAP Cloud ALM test preparation supports step instructions, expected results, references and an indication of whether evidence is required. This creates the structure against which execution can later be judged.
Record what actually happened
During execution, the tester records the status and compares the actual behavior with the expected behavior. When evidence is required, screenshots or supporting notes should prove the relevant outcome rather than capture unrelated screens. The objective is to preserve enough context for another person to understand the result without having to recreate the tester’s memory.
Failed results need defect traceability
If the actual result does not meet the expected result, the evidence should support a reproducible defect. The defect relation creates a bridge between test execution and correction work: what failed, where it failed, what evidence supports the observation and who owns the issue. When the correction is available, retest evidence should show whether the original acceptance condition is now met.
Finished test runs preserve history
SAP Cloud ALM keeps execution information with the test run, including detailed statuses, results, evidence and related defects. Finished execution records provide an audit trail of who tested, what result was recorded and how exceptions were handled. Governance should prevent casual rewriting of old evidence after a result has been accepted or closed.
What good evidence looks like
Good evidence is proportionate. It identifies the scenario, contains the minimum proof needed for review, uses clear names or notes, avoids exposing unnecessary sensitive data, and stays linked to the execution record. Teams should define evidence expectations before testing so testers know when a screenshot, attachment, log, comment or defect relation is required.
Continue with How Test Cycles Are Planned, How Defects Move From Open to Closed, How Negative Test Cases Are Designed, and the Consulting & ERP Projects hub.