ISTQB definition:
Test Plan - is a documentation describing the test objectives to be achieved and the means and the schedule for achieving them, organized to coordinate testing activities. There may be different test plans for different test levels. The test plan typically includes information about the test basis, to which all the other work products will be related via traceability information. Test basis is the body of knowledge used as the basis for test analysis and design.
Test plans also include entry and exit criteria (also known as the definition of ready and definition of done) for the testing within their scope - the exit criteria are used during test monitoring and control.
A test plan is a planning document - it contains information about what is intended to happen in the future and is similar to a project plan. It does not contain detail of test conditions, test cases, or other aspects of testing. A test plan is the project plan for the testing work to be done. It is not a test design specification, a collection of test cases, or a set of test procedures. In fact, most of our test plans do not address that level of detail
Why do we write test plans? We have three main reasons: to guide our thinking, to communicate with others, and to help manage future changes.
ISO/IEC/IEEE 29119-3
The Test Plan provides a test planning and test management document. Some projects may have a single test plan, while for larger projects, multiple test plans may be produced.
The outline of the Test Plan specific information is
Context of the testing
Project/Test sub-process;
Test item(s);
Test scope;
Assumptions and constraints;
Stakeholders.
Testing communication
Risk register
Product risks;
Project risks.
Test strategy
Test sub-processes;
Test deliverables;
Test design techniques;
Test completion criteria;
Metrics to be collected;
Test data requirements;
Test environment requirements;
Retesting and regression testing;
Suspension and resumption criteria;
Deviations from the Organizational Test Strategy.
Testing activities and estimates
Staffing
Roles, activities, and responsibilities;
Hiring needs;
Training needs.
Schedule.
IEEE 829
This standard for test plan documentation is used for software and system testing. It is a good “template” for writing your own test plan documents.
The test plan consists of:
Test Plan Identifier: Create a unique number with which to identify the plan. This number may include version information and the level of software it’s related to;
References: A list of documents that support the test plan. These might include a project plan, functional specifications, or corporate guidelines;
Introduction: A summary of the test plan, including the purpose of the testing project and scope;
Test Items: The systems and subsystems which will be tested;
Features To Be Tested: The individual features that will be tested within the systems/subsystems during the testing project;
Features Not To Be Tested: A list of features that will not be tested;
Approach: The overall strategy of how the tests will be performed;
Pass/Fail Criteria: Completion criteria for the test (minimum number of defects, percentage of passed tests);
Suspension Criteria: Specify what constitutes pausing the test. This might be when a certain number of defects are found;
Test Deliverables: The artifacts created by the testing team that is to be delivered upon completion of the test. These could be tested cases, output from testing tools, and reports;
Testing Tasks: Any dependencies or remaining activities that must be done;
Environmental Needs: Any specific tools or hardware that are needed for the tests;
Responsibilities: Who’s in charge of the test team and project? This may include training, guiding the strategy, and identifying risks;
Staffing And Training Needs: What resources are needed? Does anyone need additional or special training in order to conduct the test?;
Schedule: Details on when the testing will take place;
Risks And Contingencies: The overall risk of the project as it pertains to testing. This might be a lack of resources or delayed delivery of the software from the development team;
Approvals: Who signs off on the testing project and approves it to proceed to the next step?
Human language:
You may wonder when the right time is to create a test plan. A test plan should be written after a test strategy is already in place. Both of these activities should happen early in the project’s life cycle. The process of test planning begins at the beginning of the project with the bare minimum of details, and as the project moves forward, more information is added. Creating a test plan is an ongoing activity and requires continuous monitoring and updates. The draft version of the test plan can start in parallel with the requirement analysis, as it is not always necessary to wait for this to be complete. A test manager or test lead owns the test plan, and the document is updated based on discussion and input from the entire QA team. Once the test plan has been approved, it is shared with the QA team, development team, project managers, business analysts, and business owners.
Test plans may apply across multiple projects
(at the program level)
or to a single project
(project test plan/master test plan)
or to a specific test sub-process
system test plan;
integration software test plan;
sub-system test plan;
subcontractor software test plan;
unit software test plan.
or performance test plan
or to a specific iteration of testing
Test plans vary across teams, industries, and projects. There is no single set of parameters that makes a test plan “correct”. There are, however, certain things that make test plans useful and valuable.
Key parts of any test plan are:
Test Plan Identifier;
References;
Introduction;
Test Items;
Features to be tested;
Features not to be tested;
Stakeholders;
Approach;
Pass/fail criteria;
Suspension and resumption criteria;
Testing activities and estimates;
Test deliverables;
Testing environment needs;
Risks And Contingencies;
Staffing and training needs - roles, activities, and responsibilities;
A schedule;
Approvals.
A test plan is a critical part of a testing team’s alignment and success. It is an up-to-date document that can be easily accessed and read by the entire team at any point, to understand the overall testing objectives.
Conclusion:
So, if you are asked at an interview: What is a Test Plan? What does the test plan consist of? The best way to answer is:
A test plan - is a document detailing the objectives, resources, and processes for a specific test for a software or hardware product. The plan typically contains a detailed understanding of the eventual workflow.
In general, your test plan should document what to test, what not to test, pass/fail criteria, test deliverables, the testing environment needs, responsibilities, staffing and training needs, a schedule, risks and mitigation, and approvals.