Test Plan is a fairly small topic, but I still want to cover it early in its own article.
The concept
A Test Plan is, basically, the plan for carrying out testing. It should be completed and put into operation when the sprint (or project) starts. It sets the direction, content, strategy and timing of the testing work.
Who writes the Test Plan? The person leading the test team, usually the Test Lead. It is written during the sprint planning phase.
The Test Plan is based on:
- The Project Plan.
- The sprint requirements.
- The acceptance criteria.
If you have forgotten what a requirement is, go back to SDLC, or read Reading and Clarifying Requirements for the detailed version.
The Project Plan is exactly what its name suggests, and its shape depends on the project, so there is no need to discuss it here.
Acceptance criteria are the criteria by which a software product is considered complete and acceptable to the customer. They matter to the Test Plan because they tell us whether the product is ready for handover and acceptance. They define the conditions under which a feature or function is complete.
For a login feature, acceptance criteria might be:
- Users can enter an account, password and confirmation CAPTCHA.
- Users can log in only with valid credentials.
- There is a password-reset feature.
- After five consecutive wrong passwords, the account is temporarily locked.
If the build handed over by development has no lockout after five wrong passwords, the feature is not complete and cannot be handed to the customer. If the feature exists but locks after three attempts rather than five, it also fails the acceptance criteria and goes back to development.
Test Plan structure
A Test Plan usually contains:
- Introduction — a rough introduction to the test plan, who wrote it and who is involved.
- Requirements — the customer's requirements.
- Acceptance criteria — the acceptance criteria.
- Strategy — the testing strategy.
- Resources — people such as testers and developers, hardware and tools.
- Milestones — events and dates in the testing phase.
- Deliverables — testing work products.
- Exit criteria — conditions for stopping testing.
The biggest question marks are usually Strategy and Exit Criteria.
Strategy sets out:
- Test scope: what will and will not be tested.
- Test levels: which levels there are, who performs them and when. See Testing Levels.
- Test types: the kinds of testing to perform; a later article covers these.
- Test techniques: the test techniques to use; there will be a separate article for them too.
- Test tools: the tools to use.
- And so on.
Exit criteria are the conditions for stopping testing. Roughly, they are the quality requirements that the features named in the acceptance criteria must meet. Acceptance criteria describe the required functionality; exit criteria describe the required quality. Exit criteria can also cover coverage, the rate of outstanding defects and risk.
We cannot achieve a perfect, bug-free product, so testing cannot continue forever.
Examples of exit criteria:
- Fewer than 5% of outstanding defects are severity Major or above, ensuring serious issues are resolved before release.
- Branch coverage is above 80%, giving enough code coverage to reduce risk from untested code.
- Fewer than 5% of defects escape system testing, limiting the number that slip through that phase.
Typical question: What is the purpose of a test plan?
Typical question: What is the content of a test plan?
Typical question: What is the difference between acceptance criteria and exit criteria?
