Involved in the challenges of Automotive SPICE, particularly software qualification tests? Read on for a quick overview of key information on SWE.6, a key process from VDA Scope, including a video and our free white paper.
back to Automotive SPICEAutomotive SPICE® is a trademark of VDA QMC.
The Software Qualification Test process in Automotive SPICE® (also known as SWE.6) helps your organization to ensure that the integrated software meets the software requirements.
What is the Software qualification test? The expectation is that you already have software requirements, so the goal is to check against these requirements and determine if they are fully met and correctly implemented.
Since this process is carried out shortly before delivery of the software, either directly to the customer or as a basis for the system, there are close relationships to processes such as Project Management (MAN.3), Configuration Management (SUP.8), Product Release (SPL.2) and of course Software Requirements Analysis (SWE.1).
If the Software Qualification Test does not work well, errors can go undetected and customer satisfaction is going to drop. The test environment depends on the product. Examples are SIL, PIL or HIL.
The following are the most important aspects of Software Qualification Test in Automotive SPICE®.
Interested in finding out more about software qualification tests (SWE.6), the Automotive SPICE® process from VDA Scope? Our free white paper provides you with a summary of all key information, including an extract from our book on Automotive SPICE® Essentials – ideal reading for anyone new to the topic of process improvements.
Like all testing and supporting processes, software qualification testing requires the development and definition of a testing strategy. You may have a separate test strategy for each test level, but it is better to develop and coordinate the test strategy across all test levels. This ensures that all requirements are covered, and redundancies are avoided.
The test strategy should cover the following topics:
Of course, this process has a strong connection to SUP.9 Problem Resolution Management, so you can use either the test strategy or the defect management strategy to document how to deal with failed tests.
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
This expectation may sound trivial, but it may be anything but…
The process expects a selection of test cases to be performed for the various tests, depending on goal of the test and the coverage. The aim and expectation are that for the different deliveries the software is properly tested on the basis of the afore mentioned test strategy.
The idea is that you can have deliveries with different expectations. An example for a strategy could be that you have complete coverage of all implemented software requirements for the important deliveries.
For minor deliveries, only the delta of implemented requirements since the last delivery is tested.
For this approach, of course, the right test cases must be selected. Another possible situation for test case selection would be the regression test, which covers change requests and/or bug fixes. Here, test cases are selected that cover the change request or bug, and the effects that they can have. The latter means that dependencies on requirements that can be affected by the change request or bug fix are also tested.
This process also requires that you ensure traceability between your software test cases and software requirements.
Traceability can be established through hyperlinks like in DOORS, through specific traceability tools like Rectify, through traceability matrices or through other manageable means which are supported by your tool landscape.
As part of our strategy to systematically improve development processes in the automotive electronics sector, we are also an official licensee of Automotive SPICE® – a trademark of the Association of the German Automotive Industry (VDA QMC).
The second part of this aspect is the consistency, in this case between software requirements and the software test cases. Checks for consistency are typically if the coverage is complete and correct. This can only be performed by a review.
If you cannot prove that your software is fully and correctly covered, you may release an insufficiently tested software, so it is in your best interest to ensure consistency! Hence, ensure that this review is properly performed!