3. The Automotive SPICE-Processes (VDA Scope)

3.7 SWE.5 – Software Integration and Integration Test

What is the purpose?

The individual elements of the software architecture are integrated and then tested to prove that they work together as planned and interact as described in the software architecture.

What is the benefit?

The software is gradually integrated and tested to find errors in the interactions between the elements of the software before Software Testing (SWE.6) begins. All interfaces and dynamic behaviors are tested, resource consumption is measured, and results are documented.

What is the content?

  • An integration and integration test strategy are defined, along with a regression testing strategy. These strategies align with the software architecture and release plans. (BP1, BP2)
  • Test specifications for integration are created and their traceability and consistency to the software architecture is established. (BP3, BP7, BP8)
  • The software elements are integrated in accordance with the strategy (BP6), software integration tests and regression tests are performed (BP4, BP5, BP6), and the results are summarized and reported. (BP9)
Overview of integration strategies
Overview of integration strategies

Experiences, problems and hints

  • The meaning and purpose of integration testing is often not understood. Often the interfaces are just implicitly tested via requirements-based tests. However, integration testing requires explicit verification of every relevant interface (internal and external) and of the dynamic behavior.
  • Sometimes the software architecture lacks the necessary details needed for integration testing. Often we see just a superficial block diagram with some inputs and out-puts.
  • Ideally, the test environment allows testing the interfaces in the completely integrated system. If this is not possible the software items need to be stubbed which typically requires more effort.
  • Integration testing does not have to be performed as a separate testing step. It is permissible to combine integration tests with other types of testing, e.g., Software Qualification Tests (SWE.6), as long as all relevant interfaces and dynamic behavior can be tested explicitly.

Automotive SPICE text of Software Integration and Integration Test (SWE.5)

The purpose of the Software Integration and Integration Test Process is to integrate the software units into larger software items up to a complete integrated software consistent with the software architectural design and to ensure that the software items are tested to provide evidence for compliance of the integrated software items with the software architectural design, including the interfaces.

BP1: Develop software integration strategy. Develop a strategy for integrating software items consistent with the project plan and release plan. Identify software items based on the software architectural design and define a sequence for integrating them.

BP2: Develop software integration test strategy including regression test strategy. Develop a strategy for testing the integrated software items following the integration strategy. This includes a regression test strategy for re-testing integrated software items if a software item is changed.

BP3: Develop specification for software integration test. Develop the test specification for software integration test including the test cases according to the software integration test strategy for each integrated software item. The test specification shall be suitable to provide evidence for compliance of the integrated software items with the software architectural design.

NOTE 1: Compliance to the architectural design means that the specified integration tests are suitable to prove that the interfaces between the software units and between the software items fulfill the specification given by the software architectural design.

NOTE 2: The software integration test cases may focus on

  • the correct dataflow between software items
  • the timeliness and timing dependencies of dataflow between software items
  • the correct interpretation of data by all software items using an interface
  • the dynamic interaction between software items
  • the compliance to resource consumption objectives of interfaces

BP4: Integrate software units and software items. Integrate the software units to software items and software items to integrated software according to the software integration strategy.

BP5: Select test cases. Select test cases from the software integration test specification. The selection of test cases shall have sufficient coverage according to the software integration test strategy and the release plan.

BP6: Perform software integration test. Perform the software integration test using the selected test cases. Record the integration test results and logs.

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

NOTE 4: The software integration test may be supported by using hardware debug interfaces or simulation environments (e.g. Software-in-the-Loop-Simulation).

 BP7: Establish bidirectional traceability. Establish bidirectional traceability between elements of the software architectural design and test cases included in the software integration test specification. Establish bidirectional traceability between test cases included in the software integration test specification and software integration test results.

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

 BP8: Ensure consistency. Ensure consistency between elements of the software architectural design and test cases included in the software integration test specification.

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

 BP9: Summarize and communicate results. Summarize the software integration test results and communicate them to all affected parties.

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

Output Work Products

Software item, Integrated software, Test specification, Test plan, Communication record, Review record, Traceability record, Test result, Build list

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