Before a single test case is executed, a team must agree on what will be tested, how, by whom, by when and what happens if things go wrong. That agreement lives in two documents: the test strategy and the test plan. As a fresher you will rarely write either from scratch, but you will be expected to read them, follow them and contribute sections. Interviewers also ask about them often, so knowing their structure gives you a clear advantage.
What Is a Test Plan?
A test plan is a project-level document that describes the scope, approach, resources, schedule and risks of the testing activities for a specific release or project. It is usually prepared by the Test Lead or QA Manager during the Test Planning phase of the STLC and is reviewed by the project manager, development lead and business stakeholders.
IEEE 829-Style Test Plan Sections
The IEEE 829 standard defined a widely used test plan template. It has since been replaced by ISO/IEC/IEEE 29119-3, but most companies still follow its structure:
| Section | What it contains |
|---|---|
| Test Plan Identifier | Unique ID and version, e.g. TP-TRAINAPP-R3-v1.2 |
| Introduction | Purpose of the document, project background, references |
| Test Items | Builds, modules and versions under test |
| Features to Be Tested | In-scope features mapped to requirements |
| Features Not to Be Tested | Out-of-scope items, with reasons |
| Approach | Test levels, types, techniques and tools |
| Item Pass/Fail Criteria | How each item is judged as passed |
| Suspension and Resumption Criteria | When testing stops and when it restarts |
| Test Deliverables | Test cases, RTM, defect reports, summary report |
| Environmental Needs | Servers, devices, browsers, test data, access |
| Responsibilities, Staffing and Training | Who does what; skills to be built |
| Schedule | Milestones and dates for each test activity |
| Risks and Contingencies | What could go wrong and the backup plan |
| Approvals | Sign-off by stakeholders |
Worked Example: Train Booking App, Release 3
Scope
In scope: seat search, Tatkal booking, UPI and card payment, e-ticket generation, booking cancellation and refund status. Out of scope: the admin back-office portal (tested by another team), load testing (planned for a separate cycle) and the legacy desktop website (being retired).
Approach
- Functional system testing using test cases derived with EP, BVA and decision tables.
- API testing of search and payment endpoints using Postman.
- Regression testing of existing booking flows; smoke testing on every new build.
- Compatibility testing on Android 12 to 15, iOS 17 and 18, and the three most-used browsers.
- Defects tracked in Jira; test cases managed in a test management tool.
Resources and Responsibilities
| Role | Count | Responsibility |
|---|---|---|
| Test Lead | 1 | Planning, estimation, reporting, sign-off |
| Manual Testers | 3 | Test design, execution, defect logging |
| Automation Engineer | 1 | Regression automation and CI runs |
| DevOps | Shared | Test environment and build deployment |
Schedule
| Activity | Duration |
|---|---|
| Requirement analysis and test planning | Week 1 |
| Test case design and review | Week 2 |
| Test execution cycle 1 | Week 3 |
| Defect retest and regression (cycle 2) | Week 4 |
| Test closure and summary report | Week 5, first two days |
Risks and Contingencies
| Risk | Impact | Mitigation |
|---|---|---|
| Payment gateway sandbox is unstable | Payment tests blocked | Use a mock service; escalate to the vendor early |
| Build delivered late to QA | Execution time reduced | Risk-based prioritisation; run high-priority cases first |
| Requirements change mid-cycle | Test cases become outdated | Change control process; update RTM |
Entry, Exit, Suspension and Resumption Criteria
Entry criteria (testing can start): requirements are signed off, the test environment is ready, test data is available, the build has passed smoke testing, and test cases are reviewed.
Exit criteria (testing can stop): 100% of planned test cases executed, at least 95% passed, no open Critical or High severity defects, all Medium defects reviewed and either fixed or formally deferred, and the test summary report is shared.
Suspension criteria: the smoke test fails, or a blocker defect stops more than 30% of test cases. Resumption criteria: a fixed build is deployed and the smoke test passes again.
"Most bugs are fixed" cannot be measured. "Zero open Critical defects and a pass rate of at least 95%" can. Always write criteria that anyone can check objectively.
What Is a Test Strategy?
A test strategy is a high-level, organisation-level or programme-level document that defines the general testing approach: test levels and types to be used, tools, defect management process, environments, automation policy, metrics and standards. It changes rarely and guides many projects. A test plan then applies that strategy to one specific release with concrete dates, people and features.
Test Plan vs Test Strategy
| Aspect | Test Strategy | Test Plan |
|---|---|---|
| Level | Organisation or programme level | Project or release level |
| Focus | General approach and standards ("how we test") | Specific scope, schedule and resources ("what, when, who") |
| Prepared by | QA Manager or Test Architect | Test Lead |
| Change frequency | Rarely changes | Updated as the project evolves |
| Derived from | Business and quality goals | The test strategy and the requirements |
| Example content | "All APIs are tested with Postman; regression is automated" | "Payment APIs tested in week 3 by Rahul on staging" |
"The test strategy is the long-term approach for how the organisation tests; the test plan applies that approach to one project, with scope, schedule, resources and risks."
In Agile teams, these documents are often lighter: a one-page test strategy on a wiki and a short test plan per release or even per sprint. The sections stay the same; only the length changes.
