How to Create a Software Test Plan Template That Actually Works

Of all the responsibilities a Test Lead or Test Manager performs, the one that is most contentious is the act of creating and maintaining a Test Plan.

So many people have so many opinions about

• Why do we need a Test Plan?
• When should you create a Software Test Plan?
• What information should go into a Test Plan?
• How frequently should a Test Plan be updated? Should it be updated at all?
• How do you manage Test Plans on Agile projects vs Waterfall ones?
• Is a Test Plan the same as Test Strategy?

And everything else under the sun.

I’ve previously covered the software testing process in an A to Z guide. The principles I discuss in the A to Z guide apply to your project or Testing team, irrespective of the methodology (Waterfall, Agile, Scrum, Extreme Programming, Test Driven Development, V model etc.) and enablers (Traditional Testing, Exploratory Tests, Smoke Tests, Black Box Tests, White Box Tests etc.) you employ.

As a follow up to the A to Z guide, in this blog, I would like to dedicate time to exclusively talk about the Software Test Plan (and Test Strategy).

“I am NOT about to introduce one more Software Test Plan template in this blog.”

Teams and organisations spend hours, days and weeks inventing and reinventing the Software Test Plan. If you search online for Test Plan template, you’ll find hundreds of different versions, from generic test plans to specific ones (like one specially tuned for Performance Testing).

What we’re about to do today, is we’ll look at how you can create a Software Test Plan template that actually works for you, your situation, your team, your projects, your organisation.

We’ll review the information you need to capture, the individuals you need to engage.

We’ll discuss how you can time creation of the Test Plan, and the detail you capture at each stage of your projects.

We’ll agree why you need Test plans even on Agile projects, and how frequently you can keep these updated.

And finally, we’ll see how you can create a Software Test Plan quickly and easily, with the help of the Test Strategy vs Test Plan – Checklist (a downloadable version of the checklist is available in the article further below).

Why do we need test plans?

Let us begin with answering this fundamental question.

“Understanding why you need a Software Test Plan will help you come up with a template that covers all bases.”

Why do we need Test plans? How do they help in planning and executing your Software Testing activities?

Understanding why you need a Software Test Plan will help you come up with a template that covers all bases.

In summary,

• You need test plans to document and share the testing approach and scope for the projects and teams you lead for your organisation.
• Communicating a plan helps you set expectations with your stakeholders – about how your Testing team will engage with a project or programme, and the activities they will perform.
• The Test Plan, more importantly, also communicates what activities your team will NOT perform.
• Stakeholders understand when they can expect to receive reports of testing progress, and the artefacts that will provide these updates.
• Test Plans help you uncover any missing elements by publishing your view of Testing scope, risks, issues etc. for others to review and add to.
• A good Test Plan also helps you forecast and plan for adequate resource support across all the projects your team are part of.

When do you start creating a test plan?

This is the clincher. The question that plagues every Test Manager.

I understand that for some of you this question can be quite challenging. And it gets complicated when we throw in your specific circumstances – technology, project type, methodology etc.

To me, however, the answer is quite simple.

Start Early

When I started off as a Test Manager, I took it upon myself to get involved with a project as early as I possibly could. Depending on the project and methodology, this could sometimes mean that I was doing it in my own time – i.e., non-billable. This was because on such projects, Testers were not expected to engage with the project until at least mid-way through the Development phase.

By getting involved early – even if was on my own time – I was able to understand the project scope and high level requirements better – and earlier – than I could have otherwise. I was involved in system design discussions that I would otherwise not have been part of. By dedicating a few (free) hours a week in the lead up to the Testing phase, I understood a lot more about the project and the challenges it faced.

I would publish a draft Test Plan and Strategy based on my understanding of the project and what the project tried to achieve. Sometimes, the draft would be ready even before the developers start coding.

How does this help?

• By publishing a draft – albeit high-level – Software Test Plan (and Strategy) early on in your project, you’re bringing awareness of the Testing needs for the project to a wide stakeholder group.
• You give your stakeholders and teams an opportunity to identify any Testing related Risks, Issues and Dependencies well before Testing is due to begin.
• You allow sufficient time for any major impediments to be addressed.
• For instance, you may identify a need to build and deploy a standalone Test environment that is separate to the ones being used by your project area due to special requirements.
• Your project team and stakeholders can provide feedback about any missing or inconsistent elements, thereby allowing you to address these issues upfront and well before any Testing begins.

In summary, it is simple good practice to get a draft out the door as early as possible in your project. This allows unforeseen issues to be identified and addressed earlier than they are otherwise.

Why (and when) are Test Strategy and Test Plan separate?

Depending on the size and scale of your project, programme, product, you may choose to maintain a separate Test Strategy and Test Plan. Then again, you may choose to merge both Test Strategy and Test Plan into a single template.

Test Strategy describes elements common to all the Test initiatives for a software project or programme. Test Plans usually delve into the detail of the system or feature being tested, and define what to test, how to test, when to test and who will test at a low level of detail.

If you’re running a large IT programme, you may want to maintain an overarching Test Strategy document that describes key enablers, risks and metrics, while maintaining separate test plans for individual test initiatives within the programme.

If you’re running a compact IT project, or one of the many projects or subprojects within a large IT programme, it is normal to create and maintain a Test Plan document specific to the project or sub-project. This Test Plan will reference a ‘mother’ document – the Test Strategy – where one exists, and inherit some key attributes – such as methodology, standards, processes, risks, issues, environments, etc.

“Do you need two different documents where one can do the work admirably?”

On the small projects, you may still choose to maintain a Test Strategy AND a Test Plan. The choice is yours – but I wouldn’t recommend it. When you look at Table 1 below, you’ll understand why.

Click here to download an Excel sheet that provides an idea of the various information segments and the level of detail you can expect to cover in a Test Strategy document vs a Test Plan:

This is by no means a comprehensive list – but I do believe it covers almost anything you may want to include in a Software Test Plan document. Go ahead and include sections that you believe aren’t in here and need to be (and let us know in the comments section below!).

Following up on my comment above about maintaining both Test Strategy AND Test Plan for smaller projects, you’ll have seen with Table 1 how many of the 50+ attributes are common to both the Test Strategy and the Test Plan.

When you’re running a small or standalone project, then, you’ve got a simple decision on your hands. Do you need two different documents where one can do the work admirably?

How do you manage test plans on Agile versus Waterfall projects?

Simple – you don’t.

You create Software Test plans when you need them – usually well before the beginning of a Testing phase. And you use the Test Plan as a continuous point of reference throughout Testing.

On Waterfall projects, it’s quite possible you create a draft Test Strategy or Test Plan early on, and then update with detailed information a couple weeks before Testing is about to begin. You then usually get the Test Strategy or Plan (or both) reviewed and approved prior to commencement of Testing.

On Agile projects, your approach will be different. I usually encourage my Test Managers to create a draft Test Plan right during Sprint 0 (zero) or the preparatory Sprint. The plan outlines pretty much the same information as a waterfall project, and can be approved before Sprints begin in earnest.

How frequently do you update Test plans?

As frequently as necessary – ideally at the beginning or end of each Test cycle for that particular project, program or initiative – to keep the Plan current and make updates where necessary.

“I make ‘Review Test Plan’ a Sprint-ly task for my Test Leads and Test Managers.”

Frequency of Update on Agile vs Waterfall projects:

This is where Waterfall and Agile projects tend to vary.

I’ve seen Waterfall projects create the draft plan, update and approve it before Testing commencement, and then stow it away until a few weeks before the next Testing phase.

Even on Agile projects, I’ve seen this ‘Waterfall’ behaviour of finalising and forgetting about the Test Plan during the Sprints. And in an effort to change this, I ask my Test Managers to constantly review the Test Plan for updates. I make ‘Review Test Plan’ a Sprint-ly task for my Test Leads and Test Managers.

Easily finding a Sample Test Plan template online

As I’ve said previously, there are tons of sample test plans out there. Research and adopt one (or many!) that suit your organisational needs. And customise, customise, customise – to suit your project needs.

I’m not fussy about templates – whatever works, works. What I am mindful of, though, is the need to capture a minimum information set in each and every Test Plan. This is where the checklist we shared can come in handy.

Click here for a downloadable version!

When you customise the table to suit your or your team’s specific situation, your team have a handy reference point to check against whenever they go about creating a Test Strategy or Test Plan.

---

Now It’s Your Turn

Creating a Software Test Plan template that works is really easy. Identify the minimum information you need on Test Strategy and Test Plan documents for your team, department, organisation, and you’ll have created an easy ready reference for whenever your team need to create a Test Plan.

Go one step further, and audit Test Plans regularly against the ‘must have’ sections (therefore introduce a ‘must-have’ section on the Checklist. This will give your team a fungible way to review and ensure their Test Plans are complete.

Whatever the project methodology, whatever Software Testing Tools and Techniques your team employ, you can rely on the Test Strategy vs Test Plan – Checklist  to give you a minimum data set that actually works – every single time!

What did you think of my Test Strategy vs Test Plan – Checklist, and the ability it provides to create a Software Test Plan template that actually works? Share your comments below.

If this helped you, then why not share with friends to make their day?