5.1 Test Planning, Strategy, Entry Criteria, and Exit Criteria
Key Takeaways
- A test plan explains objectives, scope, resources, schedule, risks, approach, communication, and criteria for the testing work, and planning is a continuous activity, not a one-time document.
- A test strategy is the broader organizational direction for testing, while a test approach is the selected way testing will be done for a specific context.
- Entry criteria define what must be true before an activity starts; exit criteria (definition of done) define what must be achieved before it can be considered complete.
- The test pyramid favors many fast low-level checks over few slow high-level ones; the testing quadrants classify tests by business/technology facing and supporting/critiquing intent.
- Running out of time or budget may end testing only when stakeholders understand and accept the remaining risk.
Planning as a Continuous Activity
A test plan is not just a document produced once at the start of a project. The ISTQB v4.0 syllabus stresses that planning is the result of deciding how testing will meet its objectives under real constraints, and that the plan is revisited and updated as the project progresses and feedback arrives. A useful plan explains what will be tested, why it matters, who is involved, when activities happen, what testware is needed, what risks are known, and how completion will be judged.
The plan also drives communication. Developers, testers, product owners, project managers, operations staff, auditors, and business stakeholders each need different parts of the same plan. A release manager cares about dates and residual risk; a tester cares about environments, data, and techniques; a regulator cares about evidence and traceability.
Common Test Plan Content
| Planning area | Practical examples |
|---|---|
| Context | Scope, objectives, test basis, test object |
| Constraints | Budget, schedule, tool limits, staffing, environment windows |
| Stakeholders | Roles, responsibilities, training, communication needs |
| Risk register | Product risks, project risks, likelihood, impact, mitigations |
| Test approach | Levels, types, techniques, deliverables, independence, metrics |
| Criteria | Entry criteria, exit criteria, suspension or resumption rules |
A test strategy is broader than one project. It describes an organization's general testing requirements and direction, usually aligned with a test policy. For example, a company may require risk-based testing, independent system testing for regulated products, automated regression for critical APIs, and documented traceability for safety features.
A test approach is the way testing is selected and performed for a specific project, release, level, or feature. It may follow the strategy, tailor it, or justify a deviation. The strategy may prefer automation, but a one-time data migration may use scripted manual reconciliation plus database checks because automating it would not be cost-effective.
Entry and Exit Criteria
Entry criteria are the preconditions for starting a test activity. Typical examples: an available test environment, a stable build, prepared test data, approved requirements, passed smoke tests, available testers, and ready testware. If entry criteria are ignored, testing can still start, but it becomes slower, riskier, and less reliable.
Exit criteria define what must be achieved before an activity is considered complete. Examples: planned coverage reached, planned tests executed, high-priority defects resolved or accepted, defect reports logged, regression run, and stakeholders informed of residual risk. Exit criteria are not a promise that the product is defect-free.
The classic exam trap is confusing entry with exit because both may mention tests. "Smoke tests have passed before system testing starts" is entry. "All planned system tests have been executed" is exit. In Agile teams, the Definition of Ready (DoR) acts like entry criteria for a story, and the Definition of Done (DoD) acts like exit criteria for a releasable increment.
The Test Pyramid
The test pyramid is a model that groups tests into layers and suggests where to invest. Lower layers (component/unit and component-integration tests) should be numerous, fast, and cheap to run; higher layers (system, end-to-end, UI tests) should be fewer because they are slower, more brittle, and more expensive. The broad base of fast automated checks gives rapid feedback, supporting continuous integration.
| Pyramid layer | Typical volume | Speed/cost |
|---|---|---|
| Unit / component | Many | Fast, cheap |
| Integration / service / API | Some | Moderate |
| End-to-end / UI / system | Few | Slow, costly |
The exam trap is to invert the pyramid by relying mostly on slow end-to-end UI tests; that gives slow feedback and fragile suites.
The Testing Quadrants
The testing quadrants (Brian Marick, used in v4.0) classify test types along two axes: business-facing vs technology-facing, and supporting the team (guiding development) vs critiquing the product (finding problems).
- Q1 technology-facing, supporting: unit and component-integration tests (often automated).
- Q2 business-facing, supporting: functional tests, examples, story tests, prototypes (often automated).
- Q3 business-facing, critiquing: exploratory testing, usability testing, user acceptance (often manual).
- Q4 technology-facing, critiquing: performance, load, security, and other non-functional tests (often tool-based).
Quadrants help plan a balanced test approach across levels and types.
Testers in Iteration and Release Planning
In release planning, testers help refine backlog items, identify product and project risks, estimate test effort, define the release-level approach, and make acceptance criteria testable. They can spot missing non-functional expectations such as response time, accessibility, security, recoverability, or compatibility.
In iteration planning, testers examine individual stories in more detail. They break testing into tasks, challenge ambiguous acceptance criteria, identify needed test data, select techniques, and estimate effort. This is a shift-left contribution because defects in requirements and examples are cheaper to fix before implementation.
Running out of time or money can become an exit condition, but only with an explicit risk decision. Ending testing because the release date arrived is not the same as satisfying quality goals. Responsible stakeholders should review what remains untested, what defects remain open, what product risks remain high, and whether release is acceptable.
Exam Traps
- A plan is not valuable only after it is published; the planning process itself exposes risks and assumptions, and the plan is updated continuously.
- Strategy is broad and organizational; approach is contextual and concrete.
- Entry criteria control when to begin; exit criteria control when to stop or declare completion.
- Exit criteria can be unmet when testing stops, but the remaining risk must be visible and accepted.
- Definition of Ready maps to entry criteria; Definition of Done maps to exit criteria.
- The pyramid favors many fast low-level tests; an inverted pyramid (mostly UI tests) is a known anti-pattern.
A team requires an approved user story, available test data, and a passed build smoke test before system testing can begin. What are these conditions?
According to the test pyramid, which mix of tests is generally recommended for fast feedback?
In the testing quadrants model, exploratory and usability testing that critiques the product from the user's perspective belongs to which group?
Which items are typical content in a test plan?
Select all that apply