#264 – Create Situational Aware Test Plans

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:

One-offQuarterlyWeeklySo often you dont notice
A scale of delivery speed

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:

HunchesExplorationTool supportedAutomated
IdeasCharters to go throughScripts to runScheduled
A scale from hunches to scheduled tests

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:

12 thoughts on “#264 – Create Situational Aware Test Plans

  1. Very interesting, thank you. I guess a few of the questions that define the context can be phased in terms of entropy, i.e. how surprising things are or how much information they contain. E.g. “the Sun came up this morning” is low entropy, but “I won the lottery” is high entropy.

    So, how surprising are these statements / how much new information do they contain:

    We will be testing X.
    Team X will be doing the testing.
    We will test using environment X.
    We will use tool X.
    Team X will need to work with team Y.

    I think the implication is that you can ignore low entropy things, but you need to tailor your plan to the high entropy ones.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.