SWE.6 Software Qualification Test
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®.
Image
The SWE.6 process under VDA Scope
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:
- the test object in question
- the methods for developing test cases and test data (e.g. development of positive/negative tests, equivalence partitioning)
- a regression test strategy, which in Automotive SPICE terminology means that you define how you want to re-test after a bug fix or change request
- the test environment
- test coverage in relation to the project plan and release plan
- entry and exit criteria and test interruption criteria
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.
Over 100 corporate customers on four continents bank on our experience.
Automotive SPICE®? We’re the experts!
We currently have 48 intacs™-certified assessors. These include ten instructors on Provisional and Competent Level.
Automotive SPICE®? We’re the experts!
As a peer reviewer, we have been continually involved in the process of designing standards since 2005. We also co-authored plug-ins for mechanical engineering and hardware engineering with intacs™.
Automotive SPICE®? We’re the experts!
We have written multiple editions of »Automotive SPICE® in Practice«, already an industry classic.
Automotive SPICE®? We’re the experts!
Benefit from over 200 people-years of cumulative project experience, often involving improvement programmes lasting several years.
Automotive SPICE®? We’re the experts!
We have now trained more than 1000 assessors according to intacs™ guidelines.
Automotive SPICE®? We’re the experts!
We have conducted over 200 assessments since 2007, on both a project and an organisational level. That is equivalent to 10,000 assessment-hours.
Automotive SPICE®? We’re the experts!
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.
The purpose of traceability is that it
- supports consistency checks, i.e. checking the completeness and accuracy of the coverage of Software requirements.
- supports the impact assessment in case of change requests or bugs.
- supports the reporting of stakeholder expectations and identify which requirements have been tested, often referred to as coverage reports.
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!
- Using AUTOMOTIVE SPICE® to achieve the required maturity levels within your key processes in development
- Systematically improving existing workflows and methods
- Evaluating the status of your process improvements through formal assessments and gap analysis
- Fulfilling the requirements of Automotive SPICE® in harmony with SECURITY, FUNCTIONAL SAFETY and AGILE METHODS
- Training your staff and assessors
