A New Age of Test Strategies?

When I first started writing strategies and plans (last century!), my naivety allowed me to think that the client got more bang for their buck the more pages I wrote.  Strategies written to novel sized, crafted works of fiction. 

Let’s take a moment to commemorate my very first strategy.  I wrote it for a piece of integration testing my organisation worked on with a large UK bank.  The organisation had a mature IT department, with well-developed processes and robust test environments.

At 40+ pages it was a relatively small document, it used the categories set out in ISTQB (or ISEB as it was then), In Scope, Out of Scope etc. with most of the content detailing items that the team and the organisation were familiar with.   I was really pleased with it, the PM was pleased with it.  No one else saw it.

So, what was the point of it?  It gave my organisation something to wave around to say ‘Yes we know what we’re doing’ but it took a long time to write, no time to read, and even less time to file away.  I never reflected on it, or thought about making improvements on it for the next project.

When was the last time you read your strategy for the project you’re working on?  Or even updated it?  Can you remember what it said?  Do your current team know what’s in it?  Does it reflect what your testing approach looks like now? 

It’s easy to speculate about what should be in a good Test Strategy, there is no one size fits all.  There are some schools of thought that test plans and strategies are not required in the world of Agile Delivery, I’m not sure I totally agree.  But I do believe there is room in taking a more necessary and sufficient approach; in tailoring the information to the project to build a more succinct usable document. 

This has lead me into adopting an alternate approach I’ve seen used in other places, Strategy on a Page or SOAP.  This format means creating the relevant information and representing it clearly and concisely on a single page.  With this in mind I use the following points to keep me on track:

• Make sure it is simple and fits on one page
• Define the key principles
• Address key points such as process, tools, scope
• Use images
• Make it Accessable
• Use as a supporting document
  

  This approach has key benefits in allowing plans to be managed and updated to reflect the current state of play so there are no surprises.  The team buy in to this as they see it every day, they understand and become the principles outlined. 

  Closing thoughts: there will always be the need for detailed approaches, in a service delivery environment clients need to understand how testing is to be delivered, what the provisions are for data and what environments etc.  But in using a necessary and sufficient approach, the strategy becomes supporting documentation for the star of the show - the bit that’s useful – the visible, understood, used and living part of the strategy.