The Test Plan Dashboard

This week I needed help develop a test plan for use in another area in the business, and found myself digging out my tried-and trusted Test Plan Dashboard (TPD) template.

The TPD is something I developed back at Kiwibank (through the suggestion of my line manager, Matt Winter), to have a simple, A3 sheet way of displaying what was planned for testing, in order to share with stakeholders and project managers.

I previously talked a little bit about it back in 2011 under Communication – Better Ways Of Doing It, however never showed the final version of what I used.

Anyway, here it is, filled out for a totally fictional project, the “Paint Mixer 2000” (by the way, if you're wondering, Mitre 10 is a New Zealand hardware chain),

I’ve found it to be an invaluable resource to help me fill out the big questions around the testing project.  Questions which of course all testers will be familiar with,

• Introduction – what is the project all about?
• In-Scope – what will we be testing?
• Out-Of-Scope – what won’t we be testing?
• Entry Conditions – when can we start?
• Exit Conditions – when can say we’re done?
• Timescales – how long do we think it’ll take?
• People – who’ll be working on the project?
• Test Environment – where will we best testing on?
• Risks – what could go wrong?

Put it to the test now.  Enlarge the image of the Paint Mixer 2000 TPD picture, and see if in just a few minutes you feel comfortable about what the product is, and what will be tested.

I’ve had phenomenal feedback from the TPD.  Originally designed as a tool to summarise a test plan, I’ve actually used it to revise the way I approach test planning over the years.  Instead of being derived from the test plan, I now use it as a consulting tool to help me build a test plan/strategy on medium to large projects, or as a substitute for a large plan on much smaller projects.

When I was on huge integration projects with a lot of testing elements (many of which you can't hope to be an expert in), I would take a blank copy around all the testing sections (including those external areas) and talk with the experienced testers there in that field or on that technology, and together we’d fill in and scope out what their testing phase would look like.

If you sit together with the experts, you can fill it in on your laptop within about 15-30 minutes, but rather than asking for a test plan at a later date and reviewing, the session is interactive and you can make enquiries of them, adding elements to either the In-Scope or Out-Of-Scope as you go.

Go around each section, and put a whole group of these together, which can be posted on the wall.  It’s like putting together pieces of a testing jigsaw.  Now when you’re looking at creating your master test plan, you can try to draw up who will be focusing on what – you may find there are some elements which simply don’t have a home, and maybe you need to negotiate to get them tested in a certain phase by yourself or an outside party.  It’s a great tool for building a big picture.

And as I learned from the BAs who I worked alongside with at Kiwibank, and used similar tools - it's about harnessing together a collaborated plan, which everyone feels listened to and ownership of, and harnesses everyone's expertise

Last year when I was working on the Building A Test Culture article that was published in the Testing Circus magazine, I was struck by something Janet Gregory said about “make testing visible”.  It’s a comment that gripped me from the moment I read it, and still does.

There is a lot of mystery around testing – much of this leads to misunderstanding.  That makes many testers understandably annoyed.  However for us as testers, the ball is squarely in our court to try and remove that.  I think the TPD is one way to do just that, because it’s a very visual way to look at what our testing charter and constraints are, and unlike a plan that’s kept in a draw, this can be kept on a wall, on display for all to see.  But not just for project managers and business owners – it should be visible for all testers as well, so they are comfortable about what they are testing to, and what the project goals are.

So have a go at making your own, play with it, get feedback and see if it helps to make testing more visible for you.