What is a Test Plan in Software Testing? (With Example)

What is a test plan?

A test plan documents the what, when, why, how, and who of a testing project. It lays out the overall objective and scope of the tests to be run. The purpose of a test plan is to set expectations and align the team for success throughout the entire testing process.

A test plan does not include the individual test cases, as it is meant to be a higher-level document. A test plan ultimately aligns teams to deliver a more reliable product to their users by orchestrating a smooth testing process.

Test planning is the first thing that should happen in the software testing life cycle. The test plan document is a living and breathing artifact – it is dynamic in the sense that it should always be up to date. So, when plans change, the test plan should be updated in order to maintain an accurate set of information for the team.

Types of test plans in software testing

Test plans can be used as supporting documentation for an overall testing objective (a master test plan) and specific types of tests (a testing type specific plan).

Master test plan: A master test plan is a high-level document for a project or product’s overall testing goals and objectives. It lists tasks, milestones, and outlines the size and scope of a testing project. It encapsulates all other test plans within the project.

Testing type specific plan: Test plans can also be used to outline details related to a specific type of test. For example, you may have a test plan for unit testing, acceptance testing, and integration testing. These test plans drill deeper into the specific type of test being conducted.

Test strategy vs. test plan

It’s not uncommon to see “test strategy” and “test plan” compared to one another or sometimes used interchangeably. It’s often the case that the test strategy is written as part of the test plan, in it’s own dedicated section of the master test plan.

A test strategy is often used at the organization level, it is a static document about the project or product. The decision to test is strategic in itself, and the test strategy lays out the “what” and “why” of testing within the organization. The test strategy rarely changes, hence it’s static nature. A test strategy is usually created by a project or product manager.

A test plan is used at the project level and is a dynamic document catered to the uniqueness of the project. It’s more specific in nature as it focuses on the when, how and who of testing. A test plan is usually created by the test lead or test manager.

The importance of a test plan

A test plan helps you and your team get on the same page. It serves as a framework and guide to ensure your testing project is successful, and it helps you control risk.

The very act of writing a test plan helps you think through things in a way you might not consider without writing them down. Therefore, the value of writing a test plan is tremendous by itself.

A test plan is a great way to communicate a testing project’s objectives across the entire team. This is especially useful in a world of remote workers, where testing teams might be spread across the globe, and asynchronous communication is more common.

When to write 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. It’s ok to have gaps and generalities in your test plan at this point, and it’s ok to go back and update the test plan as details firm up, or as things change. Remember, the test plan is a living and breathing document – it is dynamic in nature.

By writing the test plan early, you’ll set your team up for success throughout the entire testing project.

How to write a test plan

Writing your first test plan might be difficult, but it will start to feel natural the more you do it. A manager or team lead is usually responsible for writing the test plan, while others on the team contribute and support the process.

4 tips for writing a good test plan:

1. Keep it concise: It’s easy for a test plan to become overly verbose. A short and succinct test plan will be more effective and easier to read. However, every project is different. There is no set length a test plan should be – it varies by team and project. More complex projects will have longer test plans than simpler projects. A super long test plan is more likely to be ignored, so focused on brevity whenever possible.
2. Keep it organized: A test plan is often scanned for specific information throughout the testing project. It’s important to keep the information organized so teammates can easily find what they’re looking for.
3. Make it easy to read: Similar to keeping the test plan organized, you need to make it easy to read. Write the test plan with your audience in mind. Keep the language simple so that anyone can read the test plan and understand it.
4. Make it easy to update: Plans change. A testing project is likely to change at some point, and the test plan document will need to be updated in order to remain accurate. An inaccurate test plan isn’t much good. Write and store the test plan in a way that’s easy to update.

After a test plan is written

After the test plan is written it’s important to review it with the team and discuss any key dependencies on specific team members. This ensures the entire team is aligned on the test plan. A test plan review can be done asynchronous or via a real-time meeting depending on where the team is located. Reviewing the test plan can also serve as a final proofread, and uncover possible areas for improvement, gaps, or errors.

Elements of a test plan

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.

Tools like Testlodge include pre-written templates to help you get started with writing a test plan. You may find some parameters are necessary for your team, while some can be excluded.

In general, your test plan should document what to test, what not to test, pass/fail criteria, test deliverables, testing environment needs, responsibilities, staffing and training needs, a schedule, risks and mitigation, and approvals.

The IEEE 829 standard is a great resource for how to write a test plan.

IEEE 829 – A popular standard for test plan documentation

Test plans don’t need to be done a certain way, but if you’re new to writing test plans, the IEEE 829 is a good place to start. 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.

Let’s take a look at the different parts of the IEEE 829:

• 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 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 are to be delivered upon completion of the test. These could be test 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 a delayed delivering of the software from the development team.
• Approvals: Who signs off on the testing project and approves it to proceed to the next step?

Test plan example

Here’s an example test plan following the IEEE 829 format. Feel free to download it and use it as a template for your own projects!

• IEEE 829 Test Plan Example (Google Document) – Access our example test plan document in Google Docs here.
• IEEE 829 Test Plan Example (PDF) – Download the PDF file of the above test plan here.

Conclusion

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.