From the endless discussions on the proper content and contexts of a test plan, it’s apparently still needed – but what goes in it? Let’s create situational aware test plans inspired by Wardley Mapping.

ISTQB template-based test plan documents are in my personal opinion no longer industry best practice. First of all it’s bloatware. While they intend to be a springboard into considering what is relevant we have ended up with 8 page templates – where every single of the 20 topics are required information. While it looks dazzling – it’s like frosting puffed with empty calories.

What most people delivering effectively software are using is 1) modern test automation and 2) modern test case management tools to lead and manage the test activities. And there is clear research on what 24 factors correlates to high-performing teams. It seems to me the templates have been frozen stale since 2012 – and are hindering us more than helping.

What is clear is that we need new ways of working – and preferably something visual. Something lean, something that fits on one page – but is a bit more context-free than the One Page Test Plan. While the One Page test plan is as good start and looks like other “canvas” style charts, it still has some inherent assumptions on environments and people. Sometimes it’s a given which environment to use, other times not so much. So there’s clearly a difference between the givens and the tactics.

I have not put in features tested and neither traceability between tests and requirements into this template. Why would you put this in a handcrafted document, when evolved tools exists already? So for this I have focussed specifically on the elements needed to set the situational for a test activity.

It’s apparently still needed – so what goes in it?

The primary key to understanding what kind of test plan you need is the delivery speed. There’s a huge difference between continuously delivering web features every day in a business to consumer setting, as compared to one-off projects of migration legacy platforms. Here are four steps on a relative scale:

Rare	Regular	Often	Pervasive
One-off	Quarterly	Weekly	So often you dont notice

A test plan is often specific to some distinct thing with a specific deadline and wants to frame the testing activities within that delivery. The thing is, the testing happening can be a range of activities:

Hunches	Exploration	Tool supported	Automated
Notes	Crafted	Generated	Autonomous
Ideas	Charters to go through	Scripts to run	Scheduled

Given Situation vs. Specific Tactics

Sometimes details like people doing the testing, environments, tools and test data are given from the context already. Other times it’s exactly the tools, people or environments or test data that sets this test plan aside from other test plans. For each of these topics we can indeed consider the nature of them.

• Is our test data rare, or running like tap water
• Is the people needed for the testing uniquely picked for the occasion, or simply the usual lot?
• Are the environments nurtured and hand crafted – or merely auto generated VM’s?
• Is the tooling needed uniquely introduced – or already embedded know-how in the team
• Is the collaboration between the people involved in testing and fixing collaborating – or not even close?

You don’t have to score each of these topics exactly right on a scale. Just an approximate location between the two end-points enables a visualization on where-abouts you are and helps the team discuss and align on the position.

Putting it all together

When you consider the Delivery Speed, The Situation, The Scope and the Tactics – you can put it in one page. Save the page in any online format you prefer, as long as it has decent versioning and save a PDF once in a while you should be good to go if auditors come along.

Grab your version of the Situational Aware Test Plan here:

• On github: https://github.com/jesperottosen/SituationalAwareTestPlan
• As PDF: Situational Aware Test Plan
• As Image, below