Verification planning

Verification planning (V&V planning) is the activity of deciding, early in the project, how the software will be checked against its specification and user needs: which static and dynamic techniques will be used, what will be tested, by whom, when, with what resources, and how results will be recorded. Its output is the V&V plan / test plan.

Why it is required

• V&V is expensive. It can take 30–50% of total development cost, so it must be planned and budgeted like any other activity.
• Testing is linked to development. In the V-model, test plans are derived from the requirements and design, so they must be prepared while those documents are written.
• Early defect detection. Writing test plans from the requirements exposes ambiguous or untestable requirements early.
• Right balance of techniques. It decides how much to rely on inspections and static analysis and how much on testing, based on how critical the system is.
• Resource and schedule control. People, test hardware, tools and test data must be ready at the right time.
• Completeness and traceability. Every requirement is mapped to tests, so nothing is left untested.
• Standards and contracts. Critical systems and contracts often require a documented V&V plan.

Steps in verification planning

1. Define V&V objectives. Decide the required confidence level from the system's purpose, user expectations and marketing environment. A safety-critical system needs far more V&V than a prototype.
2. Choose techniques. Select the mix of static verification (reviews, inspections, static analysis, formal proof) and dynamic testing for each phase.
3. Derive test plans from the V-model. Prepare the acceptance test plan from requirements, the system integration test plan from the system specification, the sub-system integration test plan from the design, and unit test plans from detailed design.
4. Establish requirements traceability. List each requirement and the tests that check it.
5. Identify tested items. Name the products, components and documents to be tested and the features excluded.
6. Prepare the testing schedule. Fit test activities into the project schedule and allocate staff and time.
7. Define test recording procedures. State how test results, incidents and defects are logged so that tests can be audited and repeated.
8. Specify hardware and software requirements. List test environments, tools, simulators and test data needed.
9. Identify constraints and risks. Note limits such as staff shortage, late delivery of components, and the plan to handle them.
10. Review and maintain the plan. The plan is a living document; update it as requirements and design change.

Objectives -> Techniques -> Test plans (V-model)
     -> Traceability -> Schedule & resources
     -> Recording procedures -> Review/update

Example: for an online banking system, the plan may require code inspections for all transaction modules, unit tests with 90% branch coverage, integration tests for the payment gateway interface, load tests for 5,000 concurrent users, and acceptance tests by bank staff, all scheduled in the last three months of the project.