ISO 26262 Part 6 Unit Testing Requirements: A Practical Checklist Mapped to TESSY Capabilities

ISO 26262 Part 6 Unit Testing Requirements: A Practical Checklist

ISO 26262 Part 6 governs software unit design and implementation. For Indian automotive teams working toward functional safety certification, whether for AURIX-based powertrain ECUs in Pune, Cortex-M body controllers in Chennai, or ADAS processing modules in Bengaluru: Part 6 defines the unit testing requirements that must be satisfied before the software can be integrated and verified at the system level.

This article translates the relevant Part 6 tables into a practical checklist and maps each requirement to specific Razorcat TESSY capabilities.

Requirement 1: Structural Coverage Metrics (Table 9)

ISO 26262 Part 6, Table 9 specifies which structural coverage metrics apply at each ASIL level:

ASIL Level	Statement	Branch	MC/DC
ASIL A	++ (highly recommended)	+ (recommended)	-
ASIL B	++	++	+
ASIL C	++	++	++
ASIL D	++	++	++

++ = highly recommended, + = recommended, = not applicable

TESSY mapping: TESSY measures statement, branch, decision, MC/DC, and MCC coverage. All metrics are computed from instrumented code compiled by the project’s actual cross-compiler. Coverage results export as HTML and PDF reports with colour-coded source annotations showing covered and uncovered code.

Practical note: While the standard uses “highly recommended” rather than “mandatory,” assessors in practice treat ++ ratings as requirements. Indian teams targeting ASIL C or D should plan for 100% MC/DC coverage on all safety-critical functions.

Requirement 2: Systematic Test Case Design (Table 10)

Table 10 specifies test case design methods:

Method	ASIL A	ASIL B	ASIL C	ASIL D
Requirements-based testing	++	++	++	++
Equivalence class partitioning	+	++	++	++
Boundary value analysis	+	++	++	++
Error guessing	+	+	+	+

TESSY mapping: The Classification Tree Editor (CTE) implements equivalence class partitioning and boundary value analysis graphically. Engineers define input classes and boundary values in a visual tree, then generate test vectors from a combination matrix. The CTE produces a documented test design rationale, the assessor can see why each test case exists, not just that it achieves coverage.

Practical note: Ad hoc test case creation (writing test cases until coverage targets are met) does not satisfy this requirement. The assessor will ask for evidence of systematic test design. The CTE provides this evidence natively.

Requirement 3: Requirements-Based Testing

Every test case should trace to a software requirement. ISO 26262 Part 6 requires bidirectional traceability: from requirement to test case (which tests verify this requirement?) and from test case to requirement (which requirement does this test verify?).

TESSY mapping: TESSY imports requirements in ReqIF format, the OMG standard used by IBM DOORS, Siemens Polarion, and codebeamer. Test cases are linked to imported requirements, and traceability reports show both forward and backward linkages. TESSY generates traceability matrices suitable for safety case inclusion.

Practical note: If your requirements management tool exports ReqIF (most modern ALM tools do), the TESSY integration is straightforward. For teams using Excel-based requirements (common in smaller Indian engineering teams), GSAS can assist with the requirements import workflow.

Requirement 4: Regression Testing

When software units are modified, previously passed tests must be re-executed to verify that the modification has not introduced regressions. This is implicit throughout Part 6 and explicit in the change management requirements.

TESSY mapping: TESSY supports batch execution via command line, enabling automated regression testing in CI/CD pipelines (Jenkins, GitLab CI, Azure DevOps). When a developer pushes a code change, the CI pipeline triggers TESSY to re-run all affected test suites. Coverage reports are generated and compared against quality gates.

Practical note: Manual regression testing is not practical for projects with hundreds of functions and thousands of test cases. CI/CD integration is not optional for real-world ISO 26262 projects, it is the mechanism that ensures regression testing actually happens.

Requirement 5: Tool Qualification (Part 8)

ISO 26262 Part 8 requires that software tools used in safety-critical development are qualified for their intended use. Testing tools like TESSY are classified as TCL3 (Tool Confidence Level 3) because a malfunction of the tool could lead to undetected errors in the software under test.

TESSY mapping: Razorcat provides a Tool Qualification Support Package for TESSY, including:

• Tool classification documentation (TCL3 / ASIL D capable)
• Validation test suite that the safety manager executes in the project context
• Tool error detection analysis
• Reference to successful qualifications in previous projects

Practical note: Tool qualification is a project-specific activity, the qualification evidence must be generated for your specific project, compiler, and target configuration. GSAS assists with TESSY tool qualification as part of the onboarding process.

Requirement 6: Independence Between Test Design and Implementation

Part 6 recommends that test cases are derived from the software requirements and design, not from the implementation. In practice, this means:

• Test cases should be designed from the specification (what the function should do), not from the code (what the function does do)
• Structural coverage measurement is then applied to verify that the requirements-based tests exercise the implementation adequately
• Coverage gaps indicate either insufficient requirements-based tests or dead/unintended code

TESSY mapping: The workflow supports this principle: engineers first design test cases from requirements (using the CTE for systematic design), then execute them in TESSY and measure structural coverage. If MC/DC coverage is below target, the gap analysis reveals which code paths are not exercised by requirements-based tests, a signal that either additional tests are needed or the code contains unintended functionality.

Checklist Summary

For teams in Pune, Bengaluru, Hyderabad, Chennai, Mumbai, and Delhi NCR preparing for ISO 26262 unit testing:

• MC/DC coverage measurement on all ASIL C/D functions
• Systematic test case design with documented rationale (CTE)
• Bidirectional requirements traceability (ReqIF)
• Automated regression testing in CI/CD pipeline
• Tool qualification evidence for the testing tool
• Test design independent from implementation (requirements-first)
• Coverage reports suitable for safety case inclusion
• Target-based testing evidence (on-target via debug probe)

TESSY addresses every item on this list.

Why Buy from GSAS

GSAS Micro Systems is India’s authorized Razorcat partner, providing TESSY licensing with INR invoicing, ISO 26262 tool qualification support, and onboarding training that maps directly to these Part 6 requirements. Our functional safety engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR help teams configure TESSY for their specific project, compiler, target, AUTOSAR stack, and establish the unit testing workflow that satisfies ISO 26262 assessors.

Request a TESSY evaluation →