Verification Planning
What
Verification Planning - to plan when, where, by whom and to what extent the developed product should be verified in each timebox.
How
The dish
Verification Planning
Ingredients
- Development strategy
- Test specifications
- Verification and acceptance specifications
- Risk management documents
Output artefacts
Test and verification plan
Compliance matrix
Process
When planning the verification activities, you need to:
- Base the extent of the verification activities on the development strategy and the verification tests
- Determine if special activities/tests are required based on the customer's implicit safety requirements or government regulations
- Decide when, where and by whom the different verification disciplines should be performed according to the product verification specification (inspections, reviews and tests)
- Consider the order of the tests; the order is important as some tests can have a destructive impact on the system if not passed
- Book in-house or out-of-house test facilities
- Make a detailed test and verification plan for the present timebox as well as a rough plan for the rest of the timeboxes until project completion
- Include the construction of testing facilities (hardware and/or software) in your development plan
- Construct a compliance matrix (a simple table) in which you can easily state compliance (or not) with all the specific requirements, one by one, during your subsequent verification activities.
Why
In each timebox, during and after the implementation of the product features, it is mandatory to verify that the requirements stated in the Product Accept Specifications document are met. Otherwise, there is no guarantee or documentation that the product meets the customer's requirements.
The degree of verification depends on what level of completion the product has. During the implementation of the product, the developer will typically verify important parameters or features several times in each timebox. If the product is a combination of more subsystems (software, hardware and/or mechanics), this continuous verification might be done separately for each subsystem.
After the integration of the subsystems, the developed system should be tested as one unit.
The degree of the verification is usually large during the final timebox, but much smaller during the earlier timeboxes.
For hardware, this is a typical test sequence:
Hardware test sequence
For software, the typical sequence looks like this:
Software test sequence
When integrating hardware and software, the typical flow will be like this:
Hardware and software integration test sequence
Note that partially integrated parts may become subject to more integration and subsequently tests as development progress. This is indicated by the dashed arc in the figure above.
The figure is also valid for integration of several hardware parts or several software parts into a more complex part.
Example
Example of an incomplete Verification Plan
Example of a Requirements Verification Traceability Matrix:
Deployment Planning might be the next natural step to take.
