What is a test plan?

A Test Plan is a thorough document that details test strategy, objectives, schedule, estimated and required resources to validate that the product meets the specifications and requirements.

This means that apart from the scope of testing, techniques and resources, it describes the features of the product to be tested and activities to be performed at a particular level of testing. It also contains deadlines, roles and responsibilities within the team.

That being said, the content of such a document also depends on its type. Broadly speaking there are three types of test plans, as per ISTQB’s definitions:

Test plan

• “Documentation describing the test objectives to be achieved and the means and the schedule for achieving them, organized to coordinate testing activities.”
  

In short, this is a detailed document that contains not only the technical details but also the goals, bigger picture and the schedule. It does not have to contain all the nitty-gritty details and can be effectively used to communicate with team members who are not involved within product development or testing.

This is the type we are going to be covering in this post.

Level test plan

• “A test plan that typically addresses one test level.”

The level test plans are intended to have a much more involved description of the required testing, with a lot of technical information and fine-grained details. The plans cover one of the following testing levels:

• Unit Testing
• Integration Testing
• System
• Acceptance

This article from ReqTest gives a good overview of testing plans on each level if you are interested in exploring those.

Master test plan

• “A test plan that is used to coordinate multiple test levels or test types.”

A single higher-level document tying together several, potentially all, testing types. If you are planning to have several testing documents, a master test plan will unify all of them together.

Test plan is dynamic.

A Test Plan can serve as a blueprint of how the testing process is going to be implemented in a project. If done properly, it should be reached for guidance regularly, for a higher or lower level picture.

However, the plan shouldn’t be set in stone from the very beginning of a project to the end. Especially, if you take into account the pace that most projects have: the requirements constantly change, deliverables and deadlines reflect the planning procedures, which change in some cases on weekly bases.

The goal then becomes to have enough detail in the document, that would not make it rudimentary, but also not to have too much detail, which would force a great amount of change every time the product specification changes slightly. Ideally, the plan would be modified slightly as directions change, which would make it quite dynamic without becoming a burden.

Why create a test plan?

As we have briefly mentioned, and as the name suggests, a Test Plan helps to organize the testing activities to validate product functionality.

Quite naturally though, arises a question of necessity and value of such a document. Why spend all this time and effort into creating this document when you can jump right into testing? Hopefully, the following points will bring an end to these questions, and assure you that the outcome is worth the effort.

Testing is an important part of product development, which helps determine its quality. Although it takes an enormous chunk of development time, it is an essential part of it and should, or dare we say, must not be neglected.

Firstly, if you are investing time into building a timeline and a plan for the programming part, why neglect the part that will make sure it works properly?

But apart from this logical inference, there are plenty of reasons and benefits to developing a Test Plan.

One of the most important reasons is that it helps estimate the resources required for completion of testing. Those resources include:

• Human
• Number of team members involved
• Amount of time each dedicates to testing
• Technical
• Test environments
• Tools utilized
• Data collected and analyzed
• Financial
• Third-party involvement
• The budget allocated and required for completion in time

It serves as a guide book for the testing process.

Not only does it direct the approach, but it also helps keep everyone in the team on the same page.

Another benefit that relates to human resources is a clear definition of roles and responsibilities. Similar to standard development planning, it helps clear out ambiguity and sets realistic expectations.

It defines areas, as seen below, that should not be covered within testing. Therefore, eliminates the possibility of wasting team effort into unnecessarily validating some functionality.

One of the main objectives of the plan includes the definition of a schedule for testing activities. Although, often the schedule shifts and adjusts throughout the process, the timeline provides a good baseline for future judgements.

A Test Plan also serves as a piece of the communication puzzle with the client. It gives insight into the testing process and gives a more well-rounded view on the product development process. It certainly doesn’t hurt that the client ends up having more confidence in the completion of the development process.

7 steps of writing a good test plan

If you are writing a test plan for the first time, the task might be quite daunting and difficult. Pulling together all the information you need, investigating the details prior to the actual execution has a trial-and-error essence to it, and might take a long time on your first try.

Somewhat counterintuitively, testers and developers running the tests are not responsible for this task. Unless you have only a few people in the team, in which case developers might also work in some managerial capacity, writing test plans is a task for people who hold a leadership role, or are in charge of managing the testing process. Reasons for this will become quite apparent when you see the steps that need to be taken below.

Here we list 7 steps of creating a good test plan. Note that the test plan document itself usually has more sections that we mention here, and we focus mainly on the largest pieces of the document. The steps that are not mentioned are self-explanatory and usually take very little time and effort.

You can find a complete list of sections within the test plan as a cheatsheet, a simple structure for completing a full test plan for your product.

1. Understand and analyze the product

The first step in writing a good test plan is to make sure you have a good understanding of the product.

It is likely that you are already aware of all the details when it comes to your product, especially if you are in a managerial role in your team. In which case, this step might sound rudimentary, and it only implies polishing what you already have. However, in our experience, it is not rare that teams, and especially developers, would not ask the important questions about the product before getting started with testing.

To understand and analyze the product means gaining a deeper understanding of its features and functionalities. However, apart from the technical details, you also want to explore business requirements, key objectives and goals of the product.

Some of the questions you could ask are:

• Who is the end-user?
• What is the goal of a product? I.e. what the user is going to be using this product for?
• How is it going to work? What does the user flow look like?
  

Note: if you have a product specification document, it could be a good place to start to kickstart this process.

2. Develop a test strategy

Develop a test strategy? Isn’t that what we are doing right now?

There are actually quite a few differences between a Test Plan and a Test Strategy.

And as the sequence suggests, the strategy should be defined before the testing plan can be completed. Test plans convey how testing procedures are taking place. Such documents should include both higher and lower levels of detail: from objectives and goals to testing schedule, tools and environment.

A testing strategy comes in place here as it helps to establish objectives and goals within a test plan. It helps formulate the objectives of the testing, its approach and details surrounding it. You can think of the sections within a strategy document as a subset of a test plan.

Usually developed by the project manager, it is derived from the business requirements of a product. If a test plan covers the “how”, a test strategy covers the “why” and “what”.

Test strategy document is static.

This document is static precisely because it outlines the objectives and scope of testing, client communication strategy, team reporting structure, etc. You can see how these aspects of testing can and should remain consistent from the beginning of the project till the end. In fact, testing strategy documents can be applied to multiple projects, and serve as a template.

Now that we have established the differences between these two documents, we can dive into practical steps. Since test strategy and test plan documents overlap, you can see how some of the following steps are taken to complete both documents, however potentially with a different level of detail.

3. Define the scope of testing

Two of the sections that are included in a test plan, which divide the components of software to be tested into ‘in scope’ and ‘out of scope’. These sections as the names suggest consist of parts of the system to be tested and to be left out, which should be figured out while defining the “bigger picture”, i.e. the test strategy.

This definition is helpful as it clears ambiguity for all team members, and saves time in the long run.

To determine the scope of testing you can look into the following things:

1. Documentation

• Product specifications
• Client requirements

2. Available resources

• Budget
• Human resources - team members and their skills

The distinction between what should and should not be covered should be quite clear and derived from the functionality promised (as specified in the product specification documents and client requirements).

Let’s consider an example, where you are working on the initial version of an application for food delivery. In this case, things that could be in the scope include the user interface and overall functionality. Testing hardware and how the system is performing under thousands of orders might be unnecessary for the time being.

4. Identify testing types

Drawing from the scope you have outlined the previous step, you can determine the testing types you need to use to validate the functionality within that scope.

Some of the commonly used testing types includeUnit Testing, Integration testing and Regression testing. You can also separate the testing into functional and non-functional testing. These categories offer a wide umbrella, under which a variety of testing types fall.

Going back to the example given above, where we are testing a food delivery app, functional testing is definitely one of the types to employ. Having said that, within functional testing, you can also select multiple, more specific testing types.

In contrast, for the out of scope features, you wouldn’t be utilizing hardware testing and stress testing, if those are not the priority.

5. Define test objectives

Obviously, the holy grail of the goals is a defect-free piece of software. However, it is important to break it down to finer pieces and define what it means for your software to be bug-free.

Such objectives could be easily determined in two steps, assisted by the product specification, or a graphical representation of the functionality.

• Taking you have completed the first substep, this part doesn’t entail much, apart from gathering the features and functionality your application has and putting it into a concise list.
• The second substep here is to ask what exactly it means for each functionality to be valid and complete.

6. Develop a schedule

Since now you understand the scope of testing work to be done, as well as how you are going to be completing each, i.e. your goals, objectives and testing types, you can go ahead and plan it out.

This entails breaking the bigger tasks into smaller chunks and putting down deadlines. To get a better idea of how realistic the schedule is, we would recommend also assigning to each task an estimated duration to complete it. This way, you can prevent massive under- and over-estimations within the scheduling, and thus, the deadlines of your project.

7. Foresee or document potential issues and risks

One of the most important steps to take into account when defining the testing strategy is assessing the risks and potential issues. The risk here is defined as a probable future event with a potential loss. When a risk does take place it becomes an issue.

The common risks you need to document and prepare for in your test plan is lacking skills of team members, misalignment of the responsibilities, poor communication during the testing, insufficiency of budget or resources for the testing etc.

By doing pre-mortem analysis, we are brainstorming on what could go wrong, so we can act on them and make sure there is little likelihood of them occurring. Those actions are usually called risk mitigations.

These should also be considered when scheduling activities, and the overall timeline should be adjusted according to the likelihood of these events happening.

This article gives a good overview of how to assess risks for software projects, when it comes to testing, and approach their mitigation.

8. Identify roles & responsibilities

This step is pretty straight forward: outline who is responsible for what parts of the process, what roles everyone has in the team, when start to test. To assign the right testers you need to consider the skill-sets and qualifications of testers, We recommend putting these aspects in, as it helps structure the project testing plan, as well as keeping the communication clear with external members (clients, project managers, etc.).

Another tip is to combine the schedule you have built with the roles and responsibilities. Tasks could have members and the team leads assigned to them, which will help further with the organization of the whole process.

9. Define environment and tools

And lastly, bear in mind dependencies and tools you are going to be using to perform the testing. Testers need to understand the hardware and software requirements, connection details before starting the testing process.

This can be extremely helpful in several cases:

• New members joining the testing efforts
• Re-using the test plan document in the following projects
• Cross-sharing the test plan with other teams, who might be working on similar projects
• Communicating needs in purchasing tools, setting up the environment with project managers or administrators

Conclusion

Hopefully, we have convinced you that preparing a test plan is worth the time and effort, as it makes the testing process more efficient and less wasteful. It helps coordinate the activities and predetermine required steps and resources for completion of product validation.

This article gives an overview of what a test plan is and it shortlists the steps that we recommend taking in making your own document. That being said, we have focused our attention on the biggest steps, and have given explanations as to why we think you should take them. We provide a full list of sections for a test plan here, with short descriptions of each element.