DO-178C Compliance: Testing Essentials for Software Teams

During review, however, the records cannot show which requirement one test verifies or which build produced the results.

An aviation software testing strategy needs to make those connections clear.

In the United States, FAA Advisory Circular 20-115D recognizes DO-178C as an acceptable means of showing compliance.

The circular is advisory rather than a regulation, and it allows other means of compliance. Issued in 2017, it remains the FAA’s current guidance on this point. Other authorities publish their own guidance.

Structural coverage also has a defined scope: it records what code was exercised but cannot establish whether the software behaved correctly.

Key takeaways

• Derive tests from requirements. Each test should identify the requirement it verifies and the expected result before execution.
• Automate the selected coding rules. Check against the project's chosen MISRA edition during builds, and retest behavior after corrections.
• Retain coverage and qualification evidence. Tie results to an identified build, configuration, and review record.

Start with requirements and a verification plan

The Software Verification Plan describes the reviews, analyses, and tests used to address the project's applicable DO-178C verification objectives.

A compact working matrix can help organize this work. Include the requirement ID, test ID, expected result, execution environment, build identifier, and review status.

This is a practical aid, not a prescribed DO-178C data format.

Define behavior before writing tests. DO-178C expects verification tests to be developed from the high-level and low-level requirements, not from the code.

Tests generated from implementation code should not become the specification for expected behavior.

Consider this illustrative requirement, reused in the code section: when enabled is false, the module shall not acquire or latch sensor state; when enabled is true, it shall acquire once and enable the output only when the returned ready state is true.

Three requirement-derived cases follow.

• Disabled: zero acquisition calls and no output call.
• Enabled, not ready: one acquisition call and no output call.
• Enabled, ready: one acquisition call and one output call.

Define abnormal-input and hardware-dependent behavior in the project's requirements rather than inferring it from the implementation.

Preserve the requirement-to-result connection. Traceability runs in both directions. Tests trace to requirements, and source code must trace back to the low-level requirements it implements.

Checking both directions makes unreferenced code visible. Requirements-traceability capabilities can help maintain these connections.

Host-based runs in continuous integration provide early feedback on changes. Record each run's execution environment and build, and identify how its results support the verification plan.

Reviewers need to distinguish development feedback from the evidence selected to address verification objectives.

Automate coding rules without changing intended behavior

Make the analysis configuration reproducible. Store the compiler configuration, language baseline, selected coding-standard edition, and analysis settings with each build.

Static analyzers need to be configured to the compiler’s behavior and language extensions to analyze source code accurately.

Compiler settings therefore belong beside the findings. The example below uses MISRA C:2012; record the edition your project selects, since later editions exist.

Work through MISRA C:2012 Rule 13.5. The rule states that the right-hand operand of a logical && or || operator shall not contain persistent side effects.

Calls to functions that modify persistent state are a common example. Assume enabled is a stable bool and read_and_latch() returns bool while changing persistent sensor state. This form triggers the finding:

if (enabled && read_and_latch()) { enable_output(); }

The corrected form keeps acquisition conditional:

if (enabled) { const bool ready = read_and_latch(); if (ready) { enable_output(); } }

Moving read_and_latch() above the outer if would also clear this finding, but it would acquire and latch sensor state in the disabled case, violating the requirement.

The nested form preserves conditional execution. Rerun the three requirement-derived tests after the change; the disabled case catches the wrong fix.

Have an embedded-software reviewer check that this illustrative correction preserves the stated behavior.

Closing one finding does not establish MISRA conformance. MISRA conformance contributes to the broader development and verification process, but it cannot establish certification compliance on its own.

Run automated coding-standard checks alongside requirements-based unit tests and structural coverage so reviewers can connect a finding, its correction, and the retest.

Parasoft provides static analysis, unit testing, and structural coverage tools to support DO-178C compliance.

Retain the analysis settings and test results together so the team can reproduce the checks.

Close coverage gaps and retain the evidence

Use coverage to investigate gaps. The table summarizes the structural-coverage progression by software level.

It covers only structural coverage, not the complete objective set at each level. MC/DC does not apply to every project.

Modified condition/decision coverage (MC/DC) examines whether each condition independently affects a decision's outcome. Decision or condition coverage alone cannot establish MC/DC.

When code remains uncovered, check it against the requirements and assess whether the existing tests are adequate.

Any additional test needs a reviewed purpose and expected result; increasing the coverage percentage is not enough.

Keep results tied to a configuration. A practical evidence set for each requirement includes:

Reviewed test procedures with expected outcomes

• Actual results from the identified build
• Links to the requirements verified
• Coverage analysis and documented decisions about gaps
• Applicable review records
• Identified tool and build configurations

After changes, including coding-rule corrections, rerun regression tests as defined in the verification plan.

NASA's software test-planning guidance describes regression testing as checking for unintended effects of changes.

That general engineering guidance supports, rather than replaces, project-specific planning.

Continuous-integration systems can support repeat checks in the build workflow; retain the build and tool configurations with the resulting records.

Assess qualification for the intended tool use. FAA AC 20-115D recognizes DO-330 as containing its own objectives, activities, and life-cycle data for tool qualification. Qualification is specific to the project and operational environment.

A vendor's qualification kit provides supporting material, but the tool user remains responsible for qualification. Assess qualification needs against how the project uses the tool.

MISRA conformance, requirements-based testing, structural coverage, and tool qualification each address different parts of the assurance work; none alone establishes airworthiness certification.

To check the workflow, choose one representative requirement. Run its tests against an identified build in the planned environment, examine the applicable coverage, and assemble the review records for that row of the matrix.

Check whether a reviewer can trace the requirement through to the results without relying on undocumented explanations.