Plans are created as part of the startup of a project, and then often left alone during long periods of the project. As reality kicks in, the plan will become more and more invalid, leaving the reader alone in a world of false assumptions and inaccurate statements. “Plan the work, work the plan” is not an advisable strategy!
Solution: Put some reality checks into your plan and update the plan, as you wise up.
Whenever reality bites, it will change the foundation of the plan either confirming some of your assumptions or invalidating them. It will be dependencies to other plans or deliveries that will rock the boat, suggesting that you will need to question your plan at least every time you (are supposed to) receive something from others. I have seen these points mentioned as quality gates in some organizations – No matter what you call the deliveries, you will require entry criterias (or similar) to communicate your expectations to the delivery organization and to check if the delivery meets the requirements.
When you find that the delivery does not match your expectation then update the plan, communicate risk/issues to stakeholders and take corrective action to ensure that the plan reflects what you know and where that will take you and the test project.
- Test items
- Features to be tested
- Features not to be tested
- Item pass/fail criteria
- Suspension criteria and resumption requirements
- Test deliverables
- Staffing and training needs
I strongly advise that the plan is kept simple (see “KISS your test plan, but not goodbye”), and one of the reasons for this is to keep the administration workload at a minimum. In complex projects with loads of dependencies, just keeping a plan up to date can be quite a task.
Happy planning and testing!