We will explore the pros and cons of having and not having a Test Plan. How will this decision impact your software project? Here we will tell you!

Author: Juan Pablo Sánchez Rizza

If you are an experienced tester, you may know that a Test Plan is a mandatory document that Test Managers and Test Leaders often encourage their team to write for a project. But when you are working on a project that involves one or a few testers, is it really necessary to write a Test Plan for such projects?

To answer this question, let’s begin by explaining what a Test Plan is. According to the International Software Testing Qualifications Board’s (ISTQB) definition, a Test Plan is the project plan for the testing work to be done. It is not a collection of test cases where most people tend to get confused. In fact, they do not address that level of detail.

A Test Plan is one of the test deliverables prepared during the process of software testing. This one contains the details of what the scope of testing is, what the test items are, what the items test/pass criteria will be, and what is needed to set up the test environment.

For larger projects (with several testers), you might have heard of a Master Test Plan (MTP), also known as Software Test Plan or Testing Strategy, whose purpose is to provide an overall test planning and test management document for multiple levels of tests (either within one project or across multiple projects).

Why to write a Test Plan

According to ISTQB, there are three main reasons for writing a Test Plan, but thanks to our experience in testing solutions, we have added an extra motive that we consider essential:

1. It guides our thinking: It forces us to confront the challenges that await us and focus our thinking on important topics.
2. It encourages a better communication: The test planning and the plan itself serve as vehicles for communicating with other project team members, testers, peers, managers, and other stakeholders.

This communication allows the Test Plan to influence the project team and vice versa, especially in these areas:

a. testing policies
b. test scope
c. objectives and critical areas to test
d. project risks
e. product risks
f. resource considerations and constraints
g. testability of test items

3. It helps us to manage the change: As the project evolves and situations change, we adapt our plans. Written Test Plans give us a baseline against which to measure such revisions and changes. Furthermore, updating them at major milestones helps keep testing aligned with project goals and needs.
4. It helps us define the test strategy: A test strategy is an outline that describes the testing approach in order to achieve the objectives and aims and to inform the development team about some key issues in the testing process. We include the Test Approach or Strategy inside the Test Plan.

As we can see, the Test Plan helps outline the schedule for the testing process along with the roles and responsibilities of team members. In this way, it serves as a guidebook for the entire testing process.

Even though we are aware of the benefits of having a Test Plan, we also know that testers may choose not to write one, arguing, for example, these reasons:

1. Planning takes time and so does the Test Plan: Creating a Test Plan does not seem worth it since it is an extra effort if the project is very small. Sometimes, you need to start the testing process quickly, and you do not have enough time for planning. In such scenario, creating a Test Plan could seem more like a burden.
2. Changing management in the Test Plan can be challenging for dynamic projects: If you are working in an Agile environment where requirements change frequently, it can be difficult to update the Test Plan every time a new requirement or change requirement comes in. The Test Plan is useful when we begin the testing process, but as we proceed in the testing, we make fewer references to Test Plans. Ultimately, we are more focused on delivering results.
3. There is redundant Information: For example, testing staff and the schedule are a part of the Test Plan, but it will also be included in the overall project plan. Similarly, as with the ‘Item Pass/Fail Criteria’ information, it can be determined at the time of creating test cases instead of the Test Plan being created at the time.

Test Plan Structure

The format and content of a software test plan can vary depending on the processes, standards, and test management tools that are being implemented. However, exists a test plan template that was established by the IEEE 829– the industry standard for software and system documentation. This template provides a defined summary of what a test plan should contain. 

What happens if you do not have a Test Plan?

1. There is a misunderstanding about roles and responsibilities: When there are no clearly defined roles and responsibilities, it could lead to important tasks being left undone, or to an unnecessary effort, for example, when two testers work on the same task.
2. Test team does not have clear test objectives: For example, the test team is unaware of the different types of testing that should be done on a system as well as the reasons for doing the different types of tests. Without clear objectives for running tests, there is an increased likelihood that critical and essential system characteristics will not be adequately tested.
3. You do not know when the process ends: Because the exit criteria have not been specified, the testing team does not know when the software testing process ends. This is essential as it helps to finish the tasks within the stipulated deadlines without compromising the quality, functionality, effectiveness, and efficiency of the software.
4. Testing scope is not defined: This is important since the client can have false expectations regarding the amount of testing work that has to be done and the test items that are out of scope, which should not be tested.

To Sum Up

It is unquestionable that writing a Test Plan has more advantages than disadvantages. It serves as a roadmap to the testing process, as well as works as a means of communication between the team members and stakeholders.

It is also a systematic approach, so it provides better functional coverage. It enables the managers to estimate the required effort and cost of the testing process in an accurate way, and above all, it enables the test manager or leader to control and track the progress of the project.

Even though we also found some negative points such as the time and effort consumption, which is unnecessary in smaller projects or in projects that require ad hoc testing, our recommendation is –whenever there is time and testers involved from the early stages of a project– to always write a Test Plan no matter the size of the project since it is an important skill that every tester should have.

In the case you are working on a small project, the Test Plan could have up to two pages explaining the resources available, the items in and out of scope of testing, and the testing strategy, which will explain how you plan to test a software product.

Comments?  vehicles for communicating for more information. We’ll quickly get back to you with the information you need.