Topics / Engineering practice
Plan the evidence before the implementation is finished.
A software verification plan turns requirements and risks into specific checks, environments, acceptance rules and responsibilities.
Make “we will test it” specific.
For each consequential promise, identify a method, the expected observation, the environment and the person or policy that decides whether the result is sufficient. Include negative cases and failure recovery. Put unresolved expectations in a decision queue before an agent writes tests around a guess.
Illustrative example
An import must resume without duplicating data.
| Obligation | Planned check | Decision still needed |
|---|---|---|
| Retain accepted rows after interruption | Stop after a checkpoint; restart; compare persisted rows | Which checkpoint states are supported? |
| Write each row once | Run two retries concurrently with the same import ID | What should the losing retry return? |
| Reject malformed input explicitly | Supply a bad row and inspect the error and stored state | Is partial import allowed? |
Separate the plan from the report.
The plan says what will be checked. The report says what actually ran and what happened. Keep missing runs, changed fixtures and exceptions visible. A list of test names does not establish that the assertions check the promised behavior.
Record how the candidate build is identified and how results will be retained. Decide what to rerun after a relevant change. A plan that cannot survive another engineer taking over is missing useful detail.
Connect the plan to the change.
In Proof, requirements, hazards and verification links provide the structure for this work. Start with the local requirement neighborhood instead of specifying an entire product in advance. Review the generated or linked evidence with the people who already decide whether this component can ship.
For regulated work, reconcile the plan with the project’s applicable assurance requirements. A generic template cannot establish that coverage, independence or tool obligations have been met.
Try it on your software
Plan the checks for one difficult change.
Bring the intended behavior and an example of what could go wrong. Leave with a bounded evidence plan.