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 obligations into a practical checklist and maps each one to specific Razorcat TESSY capabilities.

A note on citations. ISO 26262 is a licensed, copyrighted document. GSAS does not publish its clause numbers, table numbers, row letters or rating grids. Everything below states the obligation in substance, as GSAS engineering guidance. Take it to your licensed copy and to your assessor.

Requirement 1: Structural Coverage Metrics

ISO 26262 Part 6 names three structural coverage metrics at the software unit level: statement coverage, branch coverage and MC/DC. How their recommendations move across the ASILs is the part most summaries get wrong, so it is worth stating carefully.

Statement coverage is relaxed at the higher ASILs rather than dropped, and the reason is definitional rather than a softening of rigour: 100% branch coverage implies 100% statement coverage, so once branch coverage carries the stronger recommendation, statement coverage is subsumed by it. A team reporting branch coverage has already reported statement coverage, whether or not it says so. Branch coverage is already recommended at ASIL A, so it is not introduced at ASIL B, and a plan that defers branch measurement until an ASIL B feature arrives is deferring something recommended from the start. MC/DC is recommended across the range and carries the standard’s strongest recommendation only at ASIL D.

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: The standard has no “mandatory” rating. The strongest rating it applies to any method is highly recommended, and because these metrics are alternative entries the obligation is to apply an appropriate combination and give a rationale for the combination selected. “ASIL D mandates MC/DC” is a misreading, and an assessor who has read the standard will treat it as one. Indian teams targeting ASIL C or D should plan for MC/DC on safety-critical functions and, just as importantly, plan the rationale that goes with it.

Requirement 2: Systematic Test Case Design

ISO 26262 Part 6 gives four routes to deriving test cases for software unit testing: analysis of requirements, generation and analysis of equivalence classes, analysis of boundary values, and error guessing. Requirements analysis carries the strongest recommendation at every ASIL. Equivalence classes and boundary values start out recommended at ASIL A and reach the strongest recommendation from ASIL B upward. The standard’s own worked example of the equivalence-class route is the classification tree method, which is why a classification tree tool has a specific place in this obligation rather than being a general convenience.

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 deals with confidence in the use of software tools. A tool confidence level, TCL1 to TCL3, follows from two inputs: the possibility that a tool malfunction could introduce or fail to detect an error in the safety-related work product, and the confidence that such a malfunction would be prevented or detected, whether inside the tool or by later activities in your process. A TCL1 outcome requires no qualification measures at all.

No vendor and no partner can tell you that a tool “is” TCL2 or TCL3. The classification depends on the tool functionalities you actually use, inside your specific development process, and it changes when that process changes. Only you can assign it. Any supplier who quotes a TCL for a product without reference to your process is selling you something the standard does not recognise. The ISO 26262 compliance page sets out the mechanism in full.

TESSY mapping: Razorcat states that TESSY is qualified to be used in safety-related software development according to IEC 61508, ISO 26262, EN 50128 and IEC 62304, and sells a separately purchasable Tool Qualification Package that documents the TESSY functionality to be validated, the validation activities and the test results. The TUV SUD certificate behind that (No. Z10 078930 0004 Rev. 01, valid until 2028-11-12) records TESSY as a support tool classified T2 and tested against ISO 26262-8:2018 among other standards. It carries no ASIL value, and Razorcat does not attach one to TESSY, so none is claimed here.

Practical note: The qualification package is an input to your tool usage argument, not the argument. The argument is yours, it lives in your safety plan, and it is assessed against your process, your compiler and your 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 the 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 →