Career upgrade: Learn practical AI skills for better jobs and higher pay.
Level up

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.
  • 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 define what must be achieved before it can be considered complete.
  • In iterative work, testers add value by improving story testability, acceptance criteria, risk analysis, estimates, and release-level test planning.
  • Running out of time or budget may end testing only when stakeholders understand and accept the remaining risk.
Last updated: May 2026

Planning as a Thinking Activity

A test plan is not just a document produced at the beginning of a project. It is the result of deciding how testing will meet its objectives under real constraints. 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 supports communication. Developers, testers, product owners, project managers, operations teams, auditors, and business stakeholders may all need different parts of the same plan. A release manager may care about dates and residual risk. A tester may care about environments, data, and test techniques. A regulator may care about evidence and traceability.

Common Test Plan Content

Planning areaPractical examples
ContextScope, objectives, test basis, test object
ConstraintsBudget, schedule, tool limits, staffing, environment windows
StakeholdersRoles, responsibilities, training, communication needs
Risk registerProduct risks, project risks, likelihood, impact, mitigations
Test approachLevels, types, techniques, deliverables, independence, metrics
CriteriaEntry 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 checks for critical APIs, and documented traceability for safety-related features.

A test approach is the way testing is selected and performed for a specific project, release, test level, or feature. It may follow the strategy, tailor it, or explain a justified deviation. For example, the strategy may prefer automation, but a one-time data migration may use scripted manual reconciliation plus database checks because automation would not be cost-effective.

Entry and Exit Criteria

Entry criteria are preconditions for starting a test activity. Typical examples include an available test environment, stable build, test data, approved requirements, completed smoke tests, available testers, and ready testware. If entry criteria are ignored, testing may still start, but it becomes slower, riskier, and less reliable.

Exit criteria define what must be achieved before an activity is considered complete. Examples include required coverage reached, planned tests executed, high-priority defects resolved or accepted, defect reports logged, regression tests run, and stakeholders informed of residual risks. Exit criteria are not a promise that the product is defect-free.

The exam trap is to confuse entry criteria with exit criteria 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, Definition of Ready often acts like entry criteria for a story, and Definition of Done often acts like exit criteria for a releasable item.

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 test 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 useful test 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 a risk decision. Ending testing because the release date arrived is not the same as satisfying quality goals. The responsible stakeholders should review what remains untested, what defects remain open, what product risks remain high, and whether release is still acceptable.

Exam Traps

  • A plan is not valuable only after it is published. The planning process itself exposes risks and assumptions.
  • 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 more closely to entry criteria; Definition of Done maps more closely to exit criteria.
Test Your Knowledge

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?

A
B
C
D
Test Your KnowledgeMulti-Select

Which items are typical content in a test plan?

Select all that apply

Test scope and test objectives
Risk register and test approach
Budget, schedule, stakeholders, and communication arrangements
A guarantee that no defects remain
A replacement for the organization's test policy