We are on the move! This September this site will redirect to a new UL Solutions website. Stay tuned!
SWE.4 Software Unit Verification
Busy with the verification of your software units? If you are still not sure which verification types you should use to check and prove that your software units meet the design requirements, see here for relevant info on the key process SWE.4 from the VDA scope, including video and free whitepaper.
Back to Automotive SPICEAutomotive SPICE is a VDA QMC brand.
The verification process at the software unit level in Automotive SPICE® (SWE.4 for short) helps your organization to prove that the implemented software units not only work, but also meet the requirements. These were previously specified in the detailed design (SWE.3).
The Software Unit Verification process in Automotive SPICE® helps your company to verify whether the software units implement the detailed design and the associated functional and non-functional requirements with the required quality. Ultimately, this process serves your assurance as a supplier.
Image
The SWE.4 process within the VDA scope
Still want to learn more about the Automotive SPICE® process "Verification of Software Units (SWE.4)" from the VDA scope? In our free whitepaper you will find all information summarized and a reading sample from the book "Automotive SPICE® Essentials", the book for beginners in the topic of process improvements.
Unit verification, this is the first group of tests in a series of subsequent tests.
If you do not do unit verification, there will be two negative consequences:
- Not all problems are guaranteed to be found later because the subsequent tests have a different focus, such as integration tests and requirements tests.
- However, if you find such a problem at a higher test level, you will have to re-run most of the tests in between.
The reason for this is that incorrect behavior at the unit level could mask problems at a higher test level. As you can see, this process helps you find more problems while reducing your effort and costs.
The following activities are the three most important ones of Software Unit Verification in Automotive SPICE®.
As you may know from some of our videos, a strategy is an easy to understand instructional description. This is especially important for larger, distributed projects, so that all people know how to do it.
The main purpose of the strategy is to describe how you intend to demonstrate that the software units comply with the detailed design.
Three types of verification are required, and you should explain how they should work:
- Static and dynamic analysis,
that is, checking the code with analysis tools. - Code reviews,
where coworkers read and review the code provided by a colleague. - Unit tests,
where written specifications of tests are used to demonstrate compliance with the detailed design.
In addition, Automotive SPICE® requires a regression test strategy. Regression testing simply means that if you change something in a unit, you make sure that everything that hasn't changed still works well.
A practical example: If you use Continuous Integration, you typically run all unit tests again during your nightly tests. So, the strategy would be simply the sentence I just said.
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
Three types of traceability are required here, viz. for:
- each unit in the detailed design you know which is the corresponding test spec. If you can do this vice versa, then the traceability is bidirectional.
- each unit you know the results of code reviews and static analysis.
- each unit test spec you know the unit test results.
Now what does consistency mean? For example, for the relationship between a unit in the detailed design and the corresponding test spec consistency would require that
- the unit is linked to the correct test (and not to the test of another unit)
- this test is suitable to test the unit completely.
If this is not the case, additional tests must be linked.
Consistency also requires that the tests actually test the unit correctly. In other words: no faulty tests.
This is usually referred to as a test summary report. And this summary report should be sent to the people who need this information, such as the development team, project manager, quality engineers, and so on.
Let's take a closer look at how this report should look: As the name suggests, it should summarize the results and hide unnecessary details. What is the main message that the summary report should convey? It shall show compliance with the detailed design.
I'll give you a counterexample that I often see in assessments: The report contains pie charts showing the 1520 tests that should have been performed, but of which 112 could not be performed and 89 tests failed. That's it. There is no information as to why the 112 tests could not be carried out and what the risks are. There is also no information about how big the problem is with the 89 failed tests. Nor does the report show compliance with the detailed design. In fact, the detailed design is not mentioned at all. They would have to relate the pie chart to the 956 software units, not just to the 1520 tests. I think you have understood the point. This, of course, leads to weaknesses in the assessment.
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).
- 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
