3. The ASPICE-Processes (VDA Scope)

3.6 SWE.4 – Software Unit Verification

What is the purpose?

Software Units created are verified that they implement the detailed design and non-functional requirements to the desired level of quality.

What is the benefit?

Verified software units are ready to be integrated into a product for further verification and validation. Documented tests and results are available for use in regression testing. Traceability provides a clear linkage between the software units, their detailed design, and all unit verification results.

What is the content?

  • A unit verification strategy for the verification and reverfication of software units is determined by combining code reviews, static code analysis, dynamic code analysis and software unit tests that supports the desired level of quality. Also application parameter combinations must be taken into account in the tests. (BP1)
  • The criteria for the verification of the software units are defined. This includes test cases, peer review checklists for source code reviews, and prescriptions for the static analysis and test coverage. (BP2)
  • The software units are verified according to the strategy using the verification criteria (BP3, BP4)
  • The traceability between the software units and the detailed design and the test results is ensured and checked for consistency. In addition, consistent traceability between the test specs and test results is ensured (BP5, BP6)
  • A summary of the test results and static verification results is created and communicated to the appropriate parties (BP7)

Experiences, problems and hints

  • “Static verification” means verifying code without actually executing the code. This comprises code reviews and static code analysis.
  • Defining the desired level of quality for units will help to formulate an appropriate strategy to achieve it.
  • Project delivery pressure, developer laziness and embedded challenges often lead to skipping effective unit testing, or fooling oneself into thinking that testing the unit implicitly in the full context of the rest of the software is a better, or sufficient testing. It is actually rare that a software unit is not able to be isolated and tested effectively with modern tools.
  • Unit verification often needs to align with other standards e.g. ISO 26262
  • Unit testing should include coverage of all logic – branches and paths, internal and external interfaces, dynamic behaviors, boundary conditions, error checking, and calculations etc.
  • Appropriate peer reviews should be performed based on the desired level of quality for the unit, for example inspection for units that are ASIL D, peer reviews for non-ASIL related units.
  • All aspects of the unit test must be documented and demonstrable. It is expected that the planning of the software unit test, the verification criteria, the test specifications and the test results are documented and available.
  • Traceability to the design and software unit test cases is often ensured using naming conventions.

Automotive SPICE text of Software Unit Verification (SWE.4)

The purpose of the Software Unit Verification Process is to verify software units and to provide evidence for compliance of the software units with the software detailed design and with the non-functional software requirements.

BP1: Develop software unit verification strategy including regression strategy. Develop a strategy for verification of the software units including regression strategy for re-verification if a software unit is changed. The verification strategy shall define how to provide evidence for compliance of the software units with the software detailed design and with the nonfunctional requirements.

NOTE 1: Possible techniques for unit verification include static/dynamic analysis, code reviews, unit testing etc.

BP2: Develop criteria for unit verification. Develop criteria for unit verification that are suitable to provide evidence for compliance of the software units, and their interactions within the component, with the software detailed design and with the non-functional requirements according to the verification strategy. For unit testing, criteria shall be defined in a unit test specification.

NOTE 2: Possible criteria for unit verification include unit test cases, unit test data, static verification, coverage goals and coding standards such as the MISRA rules. 

NOTE 3: The unit test specification may be implemented e.g. as a script in an automated test bench.

 BP3: Perform static verification of software units. Verify software units for correctness using the defined criteria for verification. Record the results of the static verification.

NOTE 4: Static verification may include static analysis, code reviews, checks against coding standards and guidelines, and other techniques.

NOTE 5: See SUP.9 for handling of non-conformances.

 BP4: Test software units. Test software units using the unit test specification according to the software unit verification strategy. Record the test results and logs.

NOTE 6: See SUP.9 for handling of non-conformances.

 BP5: Establish bidirectional traceability. Establish bidirectional traceability between software units and static verification results. Establish bidirectional traceability between the software detailed design and the unit test specification. Establish bidirectional traceability between the unit test specification and unit test results.

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

 BP6: Ensure consistency. Ensure consistency between the software detailed design and the unit test specification.

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

 BP7: Summarize and communicate results. Summarize the unit test results and static verification results and communicate them to all affected parties.

NOTE 9: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

 Output Work Products

Test plan, test specification, communication record, review record, traceability record, verification results, test result, analysis report

If you wish to continue to the next chapter click here: