Welcome,
for our todays A-SPICE process review. In the last post we managed to close up the left side of the V-model. With SWE.4 – Software Unit Verification we will enter the right site of the V, focusing on testing activities. As the ID already refers, we will begin with the software area.
Let´s go
ID: SWE.4
Process name: Software Unit Verification
Process purpose: Verify our software units and deliver evidence for compliance of every software unit within the software detailed design and relevant software requirements (functional & Non-functional)
Process outcomes: We accomplished this process if we:
- have established and developed a software unit verification strategy including regression strategy to verify the software units
- develop software unit verification criteria according to software unit verification strategy, suitable to provide evidence for compliance of the software units within the software detailed design and its requirements (functional & Nonfunctional)
- can show that our software units are verified according to the software unit verification strategy and the software unit verification criteria and its results are documented
- shown our consistency & traceability between software units, criteria for verification and verification results
- have communicated all summarized results of the unit verification to all relevant stakeholder
Base practices:
SWE.4-BP.1: Develop software unit verification strategy including regression strategy
We start of with (what a surprise) the development of a verification strategy of the software units and in addition to that the regression strategy for reverification in case of a change within given software unit. Part of the verification strategy shall describe the provision of evidence for compliance of relevant software units, their software detailed design and non-functional requirements. (To verify your units, you could possibly use static/dynamic analysis, unit testing, code reviews, etc.
As a result of this process we will expect:
- 08-52 Test Plan
SWE.4-BP.2: Develop criteria for unit verification
The next BP covers the development of unit verification criteria. They need to be appropriate for compliance of the software units, and their interactions within every component, also with software detailed design and the non-functional requirements according to verification strategy. For the testing of units, the criteria must be defined in unit test specification.
Relevant criteria for unit verification could include unit testcases, unit testdata, static verification, coverage for/of goals and coding standards such as the MISRA rules.
The representation of a unit test specification may be solved e.g. as a script in an automated test bench.
This will lead us to following WP:
- 08-50 Test Specification
SWE.4-BP.3: Perform static verification of software units
Lets use our newly defined criteria to verify relevant software units for their correctness. The results of static verification shall be recorded.
Static verification may consist of static analysis, code review, checks against coding standards and guidelines, and other techniques.
For non-conformances please check SUP.9
Our process outcome need to be documented in:
- 13-19 Review Records
- 13-25 Verification Results
- 13-50 Test Result
- 15-01 Analysis Report
SWE.4-BP.4: Test software units
Now is the part to test our software units based on the unit test specification and software unit verification strategy. The outcome (Test results, logs) shall be recorded.
In case of non-conformances please check SUP.9
As in BP.3 the results are stored in:
- 13-19 Review Record
- 13-25 Verification Results
- 13-50 Test Result
- 15-01 Analysis Report
SWE.4-BP.5: Establish bidirectional traceability
Here we are again. Traceability needs to be established between:
- Software units and static verification results
- Software detailed design and unit test specification
- Unit test specification and unit test results
Bidirectional traceability also supports coverage, consistency and impact analysis
Everything needs to be documented within:
- 13-19 Review Record
- 13-22 Traceability Record
SWE.4-BP.6: Ensure consistency
Ensure consistency between our software detailed design and unit test specification
Consistency is also being supported via BP.5 Traceability and can be shown within the review records
The results are identical to the one in BP.5 so we´re talking about:
- 13-19 Review Record
- 13-22 Traceability Record
SWE.4-BP.7: Summarize and communicate results
Summarize the unit test results and static verification results and provide them to all relevant stakeholders.
Giving all necessary information of test case execution in a summarized view, will give other stakeholders the possibility to understand upcoming consequences.
Results are:
- 13-04 Communication Record
- 13-25 Verification Results
- 13-50 Test Results
Thank You!!
Please find the overall picture of all processes below.
See you next time with
- SWE.5 Software Integration and Integration Test