What is a Test Plan? - Test Documentation
A test plan is a document prepared by the test lead or a senior team member.
It provides comprehensive information on the testing activities for a software project and describes the testing of an application.
It provides details like:
- Scope of testing
- Types of testing
- Objectives
- Test methodology
- Testing effort
- Risks and contingencies
- Release criteria
- Test deliverables
It keeps track of the possible tests that will be run on the system after coding.
Contents and Importance of a Test Plan
Contents of a Test Plan
- Objectives
- Scope of testing
- Entry criteria
- Exit criteria
- What is to be tested
- What is not to be tested
- Risk management
Importance of a Test Plan
- It helps people outside the test team — developers, business managers, and customers — understand the details of testing.
- It guides our thinking, like a rule book that needs to be followed.
- Important aspects such as test estimation, test scope, and test strategy are documented, allowing the plan to be reviewed by the management team and reused for other projects.
How to Write a Test Plan (IEEE 829)
Writing a test plan is the most important task of the test management process.
Follow these seven steps as per IEEE 829:
- Analyze the product.
- Design the test strategy.
- Define the test objectives.
- Define the test criteria.
- Resource planning.
- Plan the test environment.
- Schedule and estimate, then determine the test deliverables.
Test Plan vs Test Strategy
Test Plan
Definition
A document with complete information about testing tasks for a software project.
Focus
Test focus and project scope.
Deals With
- Test coverage
- Scheduling
- Features to be tested
- Features not to be tested
- Estimation
- Resource management
Level
Project level / Project-oriented.
Prepared By
Test Lead or Senior Team Member.
Test Strategy
Definition
A guideline to be followed to achieve the test objective and execute the test types mentioned in the plan.
Focus
Testing approach — how we are going to test.
Deals With
- Test objective
- Test environment
- Test approach
- Automation tools and strategy
- Contingency plan
- Risk analysis
Level
Organization level.
Prepared By
Test Lead.
What a Test Strategy Contains (7 Steps)
Step 1 – Scope
- Who will review the document.
- Who will approve it.
- Software testing activities with timelines.
Step 2 – Test Approach
The process includes:
- Testing levels.
- Roles and responsibilities of each team member.
- Types of testing (Load, Security, Performance, etc.).
- Testing approach.
- Automation tool (if applicable).
- Adding new defects.
- Retesting.
- Defect triage.
- Regression testing.
- Test sign-off.
Step 3 – Test Environment
- Number of requirements.
- Setup required for each environment.
- Backup of test data.
- Restore strategy.
Step 4 – Testing Tools
- Automation tools.
- Test management tools required for execution.
- Open-source and commercial tools required.
- Number of users supported.
- Planning accordingly.
Step 5 – Release Control
A release management plan with appropriate version history to ensure test execution for all modifications in that release.
Step 6 – Risk Analysis
- List all possible risks.
- Give a clear mitigation plan.
- Prepare a contingency plan.
Step 7 – Review and Approvals
- Activities are reviewed and signed off by the business team, project management, development team, and others.
- A summary of review changes is provided at the beginning of the document.
- Approved date.
- Name.
- Comments.
Test Scenario vs Test Case vs Test Script
Test Scenario
High-level functionality we have to test.
It defines what to test.
It is a single statement that covers all possible ways to test an application.
It is also called a Test Condition or Test Possibility.
Test Case
A set of actions or step-by-step execution to verify a particular feature or functionality.
A test case contains:
- Test steps
- Test data
- Preconditions
- Postconditions
It is developed for a specific test scenario to verify a requirement.
Test Script
An automated test case written in any programming or scripting language.
It is basically a set of instructions to evaluate the functioning of an application.
Attributes of a Test Case
- Test Case ID — A unique identifier for the test case.
- Test Case Name — A one-line summary.
- Description — A detailed description of the test case.
- Prerequisite / Pre-condition — A set of prerequisites to follow before executing the steps.
- Test Steps — Detailed steps for performing the test.
- Test Data — The value of the test data used.
- Expected Result — The result required to pass the test.
- Actual Result — The result after executing the steps.
- Test Result / Status — Pass or Fail.
- Executed By — The name of the person executing the case.
- Comments — Any changes you want to note.
- Automation Status — Whether the case is automated or not.
- Date — The test execution date.
How to Write Effective Test Cases
- Test cases should be simple to understand, which helps in review and retesting.
- They should focus on end-user requirements.
- They should be able to find defects.
- They should contain proper steps and test data.
- They should be reusable.
- They should express expected and actual results.
Requirement Traceability Matrix (RTM)
The RTM is a document that maps requirements with test cases and test cases back to requirements.
Its main purpose is to ensure all test cases are covered so that no functionality is missed during testing.
It is typically a worksheet that lists:
- Requirements
- Possible test scenarios
- Test cases
- Current status (Passed or Failed)
Test Bed, Test Harness & Test Environment
Test Bed
A software development environment that allows developers (and testers) to test their modules without affecting live production servers.
It is configured as per the needs of the Application Under Test (AUT).
It can sometimes be a combination of the test environment and the test data it operates on.
Test Harness
A collection of software and test data that helps test a program under different conditions and monitor its behavior and outputs.
Test Environment
A setup of software and hardware for the testing teams to execute test cases.
It supports test execution with configured hardware, software, and network.
Test Data
Test data is the input given to a software program during test execution.
It represents data that affects or is affected by software execution during testing.
It is used for:
- Positive testing (verifying that functions produce expected results for given inputs).
- Negative testing (checking the software's ability to handle unusual, exceptional, or unexpected inputs).
BRS, SRS, and FRS
BRS (Business Requirement Specification)
A formal document describing the requirements provided by the client.
It is usually created by the Business Analyst and is derived from client interaction and requirements.
SRS (System Requirement Specification)
Specifies the functional and non-functional requirements of the software to be developed.
It is created by the System Architect and is derived from the BRS.
FRS (Functional Requirement Specification)
The document describing the software's functional requirements.
Test Deliverables
Test deliverables are artifacts produced by the people involved in the process.
Examples include:
- Design documents
- Data models
- Workflow diagrams
- Test matrices
- Test plans
- Setup scripts
- Test metrics
The output of a test is an artifact (a report or document) that provides details on:
- What was tested
- How it was tested
- Scope
- Testing approach
- Results
- Issues encountered
Their main purpose is to provide adequate information about the test efforts undertaken to improve quality.
Deliverables differ at every phase of the Software Development Life Cycle:
- Before testing
- During testing
- After testing
FAQs
1. What is a test plan?
A document prepared by the Test Lead that gives complete information about the testing activity for a project, including:
- Scope
- Types of testing
- Objectives
- Methodology
- Effort
- Risks
- Release criteria
- Deliverables
2. What is the difference between a test plan and a test strategy?
A test plan is project-level and defines:
- Test focus
- Scope
- Scheduling
- Resources
A test strategy is organization-level and defines:
- Overall testing approach
- Test environment
- Tools
- Risk analysis
3. How do you write a test plan?
As per IEEE 829:
- Analyze the product.
- Design the test strategy.
- Define objectives.
- Define criteria.
- Plan resources.
- Plan the test environment.
- Schedule, estimate, and determine deliverables.
4. What is the difference between a test scenario, a test case, and a test script?
- A Test Scenario is a high-level statement of what to test.
- A Test Case is the step-by-step execution to verify it.
- A Test Script is an automated test case written in code.
5. What are the key attributes of a test case?
- ID
- Name
- Description
- Preconditions
- Steps
- Test Data
- Expected Result
- Actual Result
- Status
- Executed By
- Comments
- Automation Status
- Date
6. What is a Requirement Traceability Matrix (RTM)?
A document that maps requirements to test cases to ensure full coverage and prevent functionality from being missed.
7. What is the difference between a test bed, test harness, and test environment?
- A Test Bed is the configured environment (sometimes including test data).
- A Test Harness is a collection of software and test data used to run a program under different conditions.
- A Test Environment is the software, hardware, and network setup used to execute test cases.
8. What is the difference between BRS and SRS?
- BRS is the business requirements document from the client, prepared by the Business Analyst.
- SRS specifies the functional and non-functional requirements, prepared by the System Architect and derived from the BRS.
9. What is test data?
The input given to a program during test execution.
It is used for:
- Positive testing (expected results).
- Negative testing (handling unexpected inputs).