What is a Test Plan? The Complete Guide for Writing a Software Test Plan

What is a Test Plan? Complete Guide With Examples

Creating a software test plan is one of the most foundational concepts in software testing. However, with the advent of streamlined life cycle processes, such as Agile and DevOps, the idea of taking the time to create test plans and other forms of test documentation is often minimized or ignored altogether. This is unfortunate because there is much value in a test plan that can greatly benefit all projects, regardless of lifecycle.

It is not uncommon to hear testers and test managers say things like “We don’t do test plans because we are Agile” or, perhaps the statement is “We don’t have time for test plans.” The reality is that no matter the lifecycle approach, a test plan is a valuable tool to ensure the right resources are in place to meet the test objectives.

Even in test techniques such as exploratory testing, test charters are used as a way to outline the focus of a period of testing, along with defining who will perform the tests, and how much time will be allocated to the testing effort.

Planning is essential in any endeavor in life and business. For example, a bank will not loan money to a business without a business plan. Without a marketing plan, a business will lack focus and direction in reaching new customers. Without a project plan, any initiative will dissolve into chaos.

However, for some reason, in testing, the importance of test planning is overlooked.

Keep in mind that a test plan that is not followed has little value. If you invest the time and effort to create a test plan, then follow it while evolving the plan if needed, but don’t forget it.

It is a well-known fact that any plan will need to be adjusted once the work starts to occur. The solution is not to abandon the plan but to adapt it to the situation at hand. This especially holds true for test plans.

What is a test plan?

Think of a test plan as a project plan for your testing process.

This means that the test plan conveys how testing will be performed at a particular level (such as system testing or user acceptance testing), or for a particular type of testing (such as performance testing or security testing).

The Test Plan (sometimes also referred to as a QA Test Plan) can be seen as the instruction manual or guide for your testing effort. It describes the objectives of testing (what are you planning to verify and/or validate), the scope of testing (what will and will not be tested), together with the general and sometimes detailed schedule of the activities you want to perform (how and when are you testing).

Test plans should list the risks foreseen in the project and their respective levels so that testing can be prioritized by risk.

Perhaps the most important part of a test plan is the definition of resources needed. Resources can be seen as human (such as the people involved in the test) and technical (such as test environments, test tools, and test data).

Test Plan vs Test Strategy

A test plan and a test strategy are not quite the same thing, as we will now explain. The test plan conveys how the test will be performed. This includes defining test objectives, test approach, test tools, test environment, test schedules and team responsibilities and composition. However, before the right test approach and other planning details can be defined, a larger view of the organizational and project objectives must be defined first.

It is possible to have a great test plan in terms of formatting, but miss the critical objectives of defining what is actually needed from the test. This is where the test strategy becomes very important in defining major test objectives and making sure the test approach is in alignment with organizational needs and goals. The organizational perspective of testing is often found in a test policy.

A test strategy describes the uniqueness of the test and is a “big picture” view of the test. You might think of a test strategy as the description of the “what” and the “why” of the test.

In practical application, it is often best to define the test strategy first so that the general nature and objectives are understood. Then, you have the basic information available to create the more detailed test plan.

A very good early project activity is to get the stakeholders together and brainstorm the test strategy. It may seem odd to have a test-oriented activity so early in a project, but it gets people thinking about how one of the most critical project activities, testing, will be conducted.

Early on, details are not needed in the test strategy. In fact, that is the great thing about a test strategy – you can define it even before requirements or other specifications are defined. Details will emerge as the test plan is created.

Typical items covered in a test strategy are:

• Uniqueness of the project, such as usage and technology involved
• Critical success factors, such as reliability, correctness, usability, etc.
• Risks, such as business, project, product, and technical
• Roles and responsibilities (not necessarily by name)
• General timelines and schedules
• Levels of testing (component, integration, system, acceptance)
• Types of testing (functional, security, usability, etc.)

You have much freedom in writing a test strategy. Although a standard does exist for test strategies (ISO/IEC/IEEE 29119-3), you can still make it your own. It’s possible to have a one-page test strategy that is very effective and takes less than an hour to create.

Test strategy template example

Test strategy case study example

How to Write a Test Plan

The first test plan you write might be the most difficult. This is because you are assimilating information for the first time. The more test plans you write, the better you get at the investigation of details and the phrasing of things.

Writing a test plan is typically a test management or leadership responsibility. Others on the test team and in the organization (such as users and developers) may have input and review tasks, but it is generally up to the manager to actually write the test plan.

As mentioned above, a great starting point in creating a test plan is the definition of a test strategy. A software test strategy helps in understanding the broad objectives of the test and how a particular project or release is unique. With a test strategy in place, now you are ready to start creating a test plan.

It is typical to have gaps and vagueness in the first draft of a test plan. Many times, the information needed in a test plan will emerge over time. In fact, there may be some details of the test that do not become clear until shortly before the test. For example, details such as the features to be tested may be changing even up to the time of release.

As you write the test plan, you will discover that the writing effort becomes one of investigation as you seek to learn the details needed in the plan. A good practice is to assign certain parts of the test plan to members of the test team to investigate and document. As the author of the test plan, you can then compile and edit the information.

Perhaps one of the most important tasks in creating the test plan is to review it. The first review should be a team review involving members of the test team with knowledge of the content.

After making any needed changes, the next review should involve knowledgeable stakeholders such as project leaders, test team leaders, technical test analysts, business analysts, subject matter experts and any other people that can provide helpful perspectives in the review.

Writing the Test Plan With The Audience in Mind

One of the golden rules in writing any kind of document is to write with your audience in mind. Failing to do this will result in a document that fails to convey the kind of information needed by the readers, and will likely be ignored.

Obviously, a business-oriented audience will get lost in technical jargon and technical readers will find the plan lacking if few technical details are provided. The balance is found in being able to express technical information in ways that are understandable by the business. This has been a great need for over forty years in all areas of information technology, not just testing.

When it comes to test plans, consider that only part of the test planning details will involve information heavily based on technical details. The rest of the test plan will contain information that should be easily readable by all stakeholders, regardless of role. This is another compelling reason for conducting test plan reviews, especially the reviews involving stakeholders.

Key attributes of the test plan should be:

• Conciseness – People today do not read, they scan. Keep your sentences short and to the point, bullet points help.
• Organization – It helps to start the test plan with a general introduction, then get more detailed in the body of the plan. Good test plan templates and standards help with organizing the content. Numbered sections and sub-topics help when referring to items in the test plan.
• Readability – Use plain language understandable by most of the audience. Avoid heavy use of acronyms if at all possible.
• Adaptability to Change – Plan for change. Extreme levels of detail in the plan will require the plan to be changed more frequently in response to project changes.
• Accuracy – People should be able to rely on the information contained in the test plan as being accurate. If errors are discovered, they should be reported and corrected as soon as possible.

Keep in mind that a major goal of the test plan is to communicate details of the test to readers in all areas of an organization. Therefore, anything that enhances communication in the test plan helps connect with readers.

Sizing the Test Plan

A common question when it comes to writing a test plan is, “How long should the test plan be?”. In fact, there is no definitive answer to that question since the length of the test plan is driven by the specific context of the project.

Obviously, projects that are large and complex will require more information to convey details of the testing effort than simpler and smaller projects. A principle that is helpful to remember is that the longer the test plan, the less likely people are to actually read it. As mentioned earlier, many people scan instead of read. In addition, the longer the document, the more prone people will be to scan it.

If the test plan is perceived to be too lengthy, people may ignore it entirely. My personal guideline for test plans is to keep them less than fifteen or twenty pages, if possible.

How To Create Or Find A Test Plan Template

It is very helpful to have a software test plan template or standard with which to start. If your organization doesn’t have existing test plans or standards, there are test plan examples in books and other industry publications devoted to software testing.

However, I often advise caution in following just any test plan example you might find online. Test plans, like any document, can be flawed – in some cases, greatly flawed. So, when using a template, make sure it meets your needs and doesn’t omit important information.

The primary international standard for test documentation such as test plans, test cases, and test procedures is ISO/IEC/IEEE 29119-3. In this standard, you will find both traditional and agile test plan standards, as well as examples of both types of test plans.

While some people feel standards are constraining, standards can also be your friend. Standards can provide guidance and examples based on many years of industry experience and practice, while eliminating the need to start your test planning efforts from a blank page. Standards must be tailored to meet your needs. Therefore, it is perfectly fine to tailor and adapt the standard.

Sometimes, industry groups also share test plan templates. It is worth the time to investigate this possibility if you are in an industry such as defense, finance, automotive, or medical.

Textbooks on software testing can also be a source of test plan templates.

Here you can find an example for a test plan template:

Test plan template example

How to Deal With Changes to The Test Plan

One reason why people may tend to avoid test planning is that they know any plans will likely change. Test plans are no exception. However, the prospect of changes should not deter you from creating a test plan.

The key is to write the plan to be resilient and flexible to changes, so how does one do that?

The answer is actually based on a simple principle. The more detailed and specific the plan in terms of things like names, dates, risks, and technical details, the more brittle the test plan becomes when changes occur.

But, what about the details that need to be conveyed in a test plan? What value is the test plan without details?

When it comes to things like test objectives, scope, other more solid details, those things typically survive change better than other details. For schedules, people and other details that are more change-sensitive, a good practice is to reference them in a way that changes can be recorded without prompting a new version of the test plan.

Today, many people create test plans in content management systems that allow easy references to other items, such as schedules and estimates. If referencing the details is not feasible in your case, just try to find the balance with “just enough” detail to guide the test while also minimizing the impact from changes.

Final Thoughts

Test planning is an essential activity of testing, regardless of the project lifecycle approach. A test plan is like a project plan for testing.

In many aspects of testing, a degree of planning and preparation is needed to get the needed resources in place when you need them. Some resources, such as people and environments, may require significant preparation. The test plan is where those resources are defined and the needs of testing are expressed.

A major goal of the test plan is to communicate to the rest of the organization, and perhaps other organizations, how testing is planned to be conducted. Without a test plan, communication about testing becomes very dynamic and people may not know at any given time the goals and expectations of testing.

Just remember that no test plan is perfect, but the more experience you gain in writing test plans, the easier the planning becomes.

=======

Other articles on test planning:

• The Role of Stakeholders in Software Test Planning
• Test Planning Fundamentals (Includes an outline and template)
• Software Test Plan Templates:
  • 35 Software Test Plan Templates & Examples
  • IEEE Test Plan Template