Testing without a plan is firefighting — reactive, inconsistent, and unmeasurable
When testing has no defined scope, nobody knows what is being tested, who is responsible, or when testing is done. Testers test whatever feels urgent. Critical areas are missed. Release decisions are made on gut feel rather than evidence.
A test plan defines the what, who, how, when, and why of testing for a project or product. It is the foundation that turns testing from an activity into a managed process.
// example: uber — planning testing for a new city launch
Test Planning — CTFL 4.0.1
Test Plan vs Test Strategy
Test strategy — a high-level description of the general testing approach for the organisation or programme. Often applies across multiple projects. Defines which techniques, levels, and tools are used as a standard.
Test plan — a document describing the scope, approach, resources, and schedule for a specific project or test level. Derived from the test strategy but specific to the context.
Contents of a test plan (CTFL)
- Test scope — what is in scope and what is explicitly out of scope
- Test objectives — what the testing aims to achieve
- Test approach — which techniques, levels, and tools will be used
- Resources — testers, environments, tools, time, and budget
- Schedule — milestones, start/end dates, dependencies
- Entry and exit criteria — conditions for starting and stopping each test activity
- Risks and contingencies — known risks and mitigation strategies
// tip: Exam Tip: Know the difference between entry criteria and exit criteria. Entry criteria define the conditions that must be met BEFORE a test activity can begin (e.g., test environment is ready, build is deployed). Exit criteria define the conditions that must be met to COMPLETE a test activity (e.g., all planned tests executed, no critical open defects). Both appear in the test plan.
Entry Criteria vs Exit Criteria — Examples
| Criterion Type | Purpose | Examples |
|---|---|---|
| Entry Criteria | Conditions that must be true BEFORE testing begins |
Test environment is set up and accessible Build has been deployed and smoke-tested Test data is prepared Test cases have been reviewed and approved |
| Exit Criteria | Conditions that must be true to COMPLETE testing |
All planned test cases executed No open critical or high severity defects Test coverage target met (e.g., 90% requirements coverage) Test summary report approved by stakeholders |
Why both matter: Starting testing before entry criteria are met wastes effort (broken environment, incomplete build). Ending testing before exit criteria are met risks releasing with unacceptable quality.
Test Scope
// In Scope
Login flow with SSO
Payment processing (Stripe)
User profile management
Admin dashboard
// Out of Scope
Mobile app native features
Third-party integrations not yet contracted
Performance beyond 10k users
// Exam tip
Entry criteria = conditions to START testing. Exit criteria = conditions to FINISH testing. The exam will give scenarios and ask you to classify — remember: environment ready = entry; all tests executed = exit.
Test Strategy Approaches Compared
| Strategy Type | Focus | Best Used When |
|---|---|---|
| Analytical (Risk-based) | Prioritise testing by identified risks | Risk analysis is available; resources are limited |
| Model-based | Tests derived from a model of the system (state machine, data flow) | Well-defined system behaviour with formal models |
| Methodical | Systematic use of predefined test conditions (checklists, taxonomies) | Regulated industries requiring traceable, repeatable testing |
| Process/Standard-compliant | Follows external standards (ISO, ISTQB, DO-178C) | Safety-critical systems, compliance requirements |
| Reactive | Responds to the system as it is tested; exploratory | Specifications are incomplete; experienced team; complementary to formal |
| Consultative | Input-driven by stakeholders (what they want tested most) | Business priorities drive testing focus |
// warning: Exam Trap: "A test plan is written once and never changed." This is false. CTFL treats the test plan as a living document. It should be updated as the project progresses — when scope changes, when risks materialise, or when the schedule shifts. A plan that does not reflect current reality is worse than no plan at all.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation