SWE.6 – Software Qualification Test (A-SPICE 4.0)

Welcome back to our A-SPICE journey. This post continues my A-SPICE SWE series. Missed the others? Start with SWE.1 Software Requirements Analysis. In this post we want to finalize our activities in regards to SWE. But from now on we will focus on Version 4.0 of Automotive SPICE. Enjoy 🙂

ID: SWE.6
Process name: Software Verification
Process purpose: To verify that the fully integrated software actually meets the software requirements – both functional and non-functional – ensuring we´re delivering what was promised and nothing less
Process outcomes: What do we need to achieve?

• The verification measures are not just defined – they´re aligned directly with each software requirement, ensuring full traceability and meaningful test coverage
• Verification measures are selected based on the release scope and relevant criteria, including guidelines for regression testing
• Integrated software undergoes verification using the chosen measures, and all verification results are documented
• Consistency and bidirectional traceability are maintained between verification measures and software requirements, as well as between verification results and the measures used.
• Verification results are gathered into a summary and shared with all relevant stakeholders.

Base practices

SWE.6-BP.1: Specify verification measures for software verification
Define the verification measures necessary to demonstrate that the integrated software meets both functional and non-functional requirements outlined in the software specifications. This includes specifying:

• Appropriate verification techniques, tailored to the nature of the requirements (e.g. boundary values and equivalence classes for data range requirements or fault injection for negative testing)
• Clear pass/fail criteria
• Entry and exit criteria for each measure
• Sequence in which verification activities should be performed
• Setup of the verification infrastructure and environment.

Note: The choice of techniques should align with the type of requirement. For example, requirements focused on data ranges may benefit from boundary value testing, while error-prone areas may require knowledge-based “error-guessing”.

SWE.6-BP.2: Choosing What to Test (and Why it Matters)
Document the chosen verification measures, ensuring the selection aligns with established criteria, including those relevant to regression testing. The selected measures should provide sufficient coverage based on the release scope.

Note: Selection criteria may include requirements prioritization, ongoing development stages, the need for regression testing (e.g. due to requirements changes), or the intended application of the release, such as for test benches, track testing, or public road use.

SWE.6-BP.3: Verify the integrated software
Execute the verification of the integrated software using the selected measures, and document the results, including pass/fail status and related data for each verification activity.

Note: For handling verification results that differ from expected outcomes, refer to SUP.9 Problem Resolution Management

SWE.6-BP.4: Ensure consistency and establish bidirectional traceability
Ensure that every requirement is linked to the test(s) that verify it, and every test result can be traced back to what it was trying to prove. This two-way mapping is the backbone of impact analysis, release confidence, and audit readiness.

Note: Bidirectional traceability is essential for maintaining consistency, supporting change impact analysis, and demonstrating verification coverage. However, traceability links alone do not guarantee consistency; the linked information must also align accurately.

SWE.6-BP.5: Summarize and communicate results
Compile a summary of the software verification results and share it with all affected parties.

Note: Including key details from test case execution in the summary allows stakeholders to assess the potential impact of the results effectively.

Some Final thoughts
With SWE.6, we close the loop: we don’t just test software — we verify that what we’ve built actually meets what was defined. Every requirement gets its verification, every result is traceable, and every decision is based on evidence.

It’s not about checking boxes. It’s about getting confident.

When done right, SWE.6 becomes more than just a process — it becomes the moment where we know the software is ready to move forward. Verified, documented, and trusted.

Thanks for for your time. See you in the post.