ISO 26262 Part 8: What Test Evidence Do Automotive Auditors Actually Look For

ISO 26262 Part 8 covers supporting processes - including software tool qualification (Clause 11) and requirements on test documentation. Every automotive Tier-1 supplier and ECU manufacturer eventually sits across from an ISO 26262 auditor who asks to see their test evidence. The question is not whether you have test reports. It is whether your test reports contain the right things.

This post covers what auditors actually check - based on the requirements in Part 8 and Part 4, Section 9, for hardware-software integration testing and system testing. It is not legal advice, and it does not replace working with a certified functional safety assessor. It is a practical checklist for engineering teams preparing their first ISO 26262 audit.

What ISO 26262 Part 4 and Part 8 Actually Require for Test Evidence

The relevant requirements for test documentation appear primarily in:

• Part 4, Section 8–9: Hardware-software integration testing and system testing - test specification, test execution, and test results
• Part 8, Clause 9: Confidence in the use of software tools - requires evidence that tools produce correct results
• Part 8, Clause 11: Software tool qualification - formal qualification for tools in the development path (not required for off-the-shelf test tools unless they modify or generate safety-relevant artefacts)

The standard requires evidence of:

1. Test cases derived from requirements (traceability from requirement to test case)
2. Test case execution results (what was run, when, on what configuration)
3. Pass/fail verdict for each test case
4. Test environment specification (hardware, software, test tool versions)
5. Regression evidence (retesting after changes)

Item 1: Traceability From Requirement to Test Case

This is the element most commonly missing from test reports. Auditors ask: "For this test case, which requirement does it verify?"

The minimum acceptable answer is a test case ID linked to a requirement ID from your requirements management system (DOORS, Polarion, Jira). The auditor does not expect every requirement to have 10 test cases - they expect every safety-relevant requirement to have at least one test case, and they expect to be able to trace from the test case back to the requirement.

In TestBot, test case IDs are assigned in the test project structure. The requirement linkage is currently a manual annotation in the test case name or description - typically prefixed with the requirement ID. This is sufficient for initial audits. A formal requirements traceability matrix (requirement ID → test case ID → execution result) is the output that a compliance module would automate.

Item 2: Test Execution Evidence

Auditors check that the test was actually run - not just designed. The evidence must include:

• Timestamp: when the test was executed, to millisecond precision
• Firmware version: the exact firmware build that was tested (build hash or version string)
• Hardware configuration: ECU variant, hardware revision, any connected jigs or adapters
• Test tool version: TestBot version used for execution
• Tester identity: who ran the test (or that it was run automatically - with CI/CD reference)

TestBot's HTML and PDF reports include timestamp, agent configuration snapshot, and test tool version automatically. Firmware version and hardware configuration are typically injected as test metadata via a pre-test UDS ReadDataByIdentifier block that reads the ECU's software version DID - making the firmware version part of the test execution record.

Item 3: Pass/Fail Verdict at the Step Level

A test report that says "ECU Cold Start Test: PASS" does not satisfy Part 8 requirements. The report must show the pass/fail verdict at the individual step level - each agent action, each response, each assertion.

This is what "step-level traceability" means in practice for ISO 26262. Auditors pick a failed test case and ask to see exactly which step failed, what the expected value was, and what the actual value was. A report that cannot answer this question generates an audit finding.

TestBot's HTML report is structured with collapsible step trees per test case - each step shows the agent action, the sent payload, the received response, the expected value, and the pass/fail result. The PDF report includes the same data in a static printable format with a summary table and full step trace appendix.

Item 4: Regression Evidence

For ASIL-B and above, auditors want to see that after any change to the firmware, all affected test cases were re-run and passed. This is where CI/CD integration is most valuable for ISO 26262: every firmware build automatically generates a new test execution record with a new timestamp and build reference. The audit trail is the CI/CD build history.

The key requirement: the regression suite must be comprehensive enough to cover the safety-relevant requirements. Running 20% of test cases after a firmware change and calling it a regression is not sufficient for ASIL-C and ASIL-D components. The suite must be designed to cover all safety-relevant requirements systematically.

What Generates Audit Findings Most Often

In ISO 26262 audits of embedded product companies, the most common test evidence gaps are:

1. No requirement traceability in test cases - test cases exist but cannot be mapped to safety requirements
2. Test reports without firmware version - it is impossible to determine which build the test was run against
3. Test results at test case level only - no step-level trace; cannot verify the test actually exercised the right condition
4. No evidence of regression after change - tests were run once at a milestone but not after subsequent firmware updates
5. Test environment not specified - which hardware variant, which adapter, which test tool version was used

All five of these are solvable with structured test reports and CI/CD integration. Items 2–5 are automatically addressed by TestBot's HTML/PDF reports and CI/CD pipeline integration. Item 1 requires deliberate requirement annotation in test case naming - the one thing that must be done by the test designer, not the tool.