Test Evidence

Why it matters

A failure that is not captured when it happens is often hard to show again: the data has changed, the environment was redeployed, or the problem was intermittent. Without evidence a report may be closed as "cannot reproduce", and a pass recorded without proof can be questioned in an audit or an acceptance sign-off.

Evidence also carries risk. A screenshot can show a customer's phone number, and a network export can contain a session cookie that lets anyone holding the file act as that user. Capturing only what is needed protects the people whose data the system holds.

What counts as evidence, and how much

Evidence is any record made during test execution that supports a test result. The ISTQB Foundation syllabus names test logs, screenshots, database dumps and recordings as material a defect report may include so that the failure can be reproduced.

Evidence needs context. A screenshot alone proves only that a screen once looked like that; with the test case, run, build, environment, account role, test data and the time with its time zone, it proves what happened in that test.

• Failed test: enough for a developer to see the failure without asking you — actual next to expected, plus the logs from underneath.
• Passed test: usually the recorded result is enough. Regulated work, contractual acceptance and some UAT sign-offs require proof of passes; the test plan says which tests need it and in what form.
• Capture during execution and store the evidence with the result: evidence recreated later on another build belongs to a new test.

Screenshots and screen recordings

A screenshot is the fastest evidence of what the user saw. Capture the whole window with the address and the logged-in account visible, not a tight crop around the error; when the failure is a change, take one before and one after. Mark the problem on a copy and keep the original.

A recording shows what a screenshot cannot: order and timing. Use it for multi-step flows, flicker, slow responses and intermittent failures; keep it short and note the second the failure appears.

• Also copy error messages as text so that they can be searched; extracting text from a screenshot with OCR is the fallback.

Try it: Image to Text

Logs: browser console, network and server

Logs show what happened beneath the screen. For a web application three logs cover most failures, and the first two are in the browser's developer tools (DevTools), opened with F12 or Ctrl+Shift+I (Cmd+Option+I on a Mac).

The web testing module teaches DevTools, and the HTTP module teaches requests, headers and status codes, in depth. For now, know that each time a page talks to the server, the browser sends a request and receives a response with a three-digit status code (2xx success, 4xx a problem with the request, 5xx a failure on the server side) and headers: named lines of extra information, such as the cookie that keeps the user logged in.

• Console: JavaScript errors, failed resource loads and warnings. Copy the error as text with its file, line and time; turn on timestamps in the console settings if they are hidden.
• Network panel: every request with its method, URL, status, timing, headers and bodies. Open it before the first step and turn on Preserve log (Firefox: Persist Logs) so that a page change does not clear it. Export a HAR file (HTTP Archive, a JSON format) or copy only the failing request.
• Server logs: often out of a tester's reach. Give the developer the exact time with its time zone, since many servers log in UTC (10:14 in Riyadh, UTC+3, is 07:14 UTC), and any request id the response returned, for example in a header such as X-Request-Id (names vary). Attach the lines they find, not the whole file.

Try it: JSON Tree Viewer Try it: Timezone Converter

Privacy and security when capturing evidence

Evidence copies data into places with wider access: defect trackers, chat, email, supplier tickets. A HAR file can hold every header and body of the session, including the cookies and tokens that let anyone with the file act as that user while they remain valid. Personal data in evidence is still personal data, covered by laws such as the Saudi Personal Data Protection Law (PDPL) and by your organisation's policies.

A password, token or personal data in a log is itself a finding (the OWASP Logging Cheat Sheet says passwords, session identifiers, access tokens and sensitive personal data should not be recorded directly in logs): report it without pasting the value.

• Use test accounts and generated data, capture the browser window rather than the whole desktop, and silence notifications before recording.
• Mask with a solid, opaque box, not a light blur. In a PDF a box drawn on top leaves the text underneath; use real redaction.
• In a HAR (one entry, before cleaning, is shown below), remove the values of Cookie, Set-Cookie and Authorization, the cookies arrays that repeat them, and passwords or personal data in bodies. Chrome 130 and later leave those three headers out by default (its "sanitized" export), but the bodies stay and other browsers may keep everything, so check every file. Logging out ends many sessions, but some tokens stay valid until they expire.
• Keep evidence in the team's access-controlled tools, never in public channels, and delete it when the agreed retention period ends.

{
  "startedDateTime": "2026-09-30T07:14:52.118Z",
  "request": {
    "method": "POST",
    "url": "https://staging.example.test/api/leave-requests",
    "headers": [
      { "name": "Authorization", "value": "Bearer eyJhbGciOi..." },
      { "name": "Cookie", "value": "sid=4f9c..." }
    ],
    "cookies": [{ "name": "sid", "value": "4f9c..." }],
    "postData": {
      "mimeType": "application/json",
      "text": "{\"type\":\"annual\",\"days\":3}"
    }
  },
  "response": {
    "status": 504,
    "headers": [{ "name": "X-Request-Id", "value": "8b1f0c2e" }]
  }
}

Try it: Redact PDF Try it: Fake User Generator

Worked example: evidence for a failed leave request

A tester runs TC-LV-009, "Submit a 3-day annual leave request", in an HR portal's Sprint 42 regression run on staging, with DevTools open and Preserve log on. The tester fills the form, takes a screenshot, starts recording the browser window and clicks Submit. A spinner turns for 30 seconds, then "Request failed. Try again." appears. The tester takes a screenshot and opens My requests: the request is listed as Pending, so a user who believes the message will submit a duplicate.

The tester exports the HAR, removes the session values, copies the console error and notes the request id. With that id the developer finds the server log lines: the request was saved, then the leave service waited on a call to the approval service, and after 30 seconds the gateway in front of it stopped waiting and returned 504 (Gateway Timeout). The package attached to the run result and to DEF-1874:

Part 1:1DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  Part 2:201-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  Part 3:304-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  Part 4:405-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  Part 5:506-server.txt     log lines for 8b1f0c2e, provided by the developer
  Part 6:607-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests

• Left out of the package: the desktop, the session values, and the earlier login request in the HAR, whose body carried the test account's password.

DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  01-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  04-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  05-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  06-server.txt     log lines for 8b1f0c2e, provided by the developer
  07-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• What are browser developer tools? — MDNMDN Web Docs (Mozilla)An introduction to the developer tools built into browsers — the inspector, the JavaScript console and the debugger — for examining a page while testing it.
• OWASP Cheat Sheet Series: LoggingOWASP FoundationWhat to log and what never to log (passwords, tokens, personal data), and how to keep logs tamper-evident.
• Personal Data Protection Law (English translation)Saudi Data & AI Authority (SDAIA) · 2023The Saudi law governing personal data — why test environments should use synthetic data rather than copies of real customer records.