A New Age of Test Strategies?
Cassy Calvert
Passion for Quality and driving Business Transformation through Engineering and Process using Agile Methodologies
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.
Automation Geek
8 年That is a very detailed and, quite frankly, a scary looking plan! As I can't see the details of the image, I can only hazard a guess that it's a 'one size fits all' approach, and if I was given this to read on my first day, I would 1.) throw it in the bin and 2) leave! In my short time as a tester, I have come to realise that, unless you're doing top secret stuff such as inventing the next rocket, or a smart tank - where there are strict rules and regulations where you DO have to list every detail - then I can understand this plan. However, a testers plan should be contextual - they plan according to the environment and the software. I would not test a financial product in the same way that I test a retail application - I am testing depending on the context - quite a powerful approach to testing that gives the tester the freedom to do what they are good at. What you are trying to do, from the face of it, is trying to standardise testing in which case you should read the following article: https://www.satisfice.com/blog/archives/1464 BY THE WAY: you've misspelt Accessible - 5th bullet point down! :)
I try to make the world a better place, one step at a time.
8 年There is definitely NO one-size-fits-all approach, nor are there magic bullets either. "Keep It Simple" is something I believe applies to testing as well as development. I worked in a company where we started off with a UAT that was 20-odd pages long; by the time we'd added in all the edge cases it was four times that size. No one ever read it except for the testers...
Good reminder on keeping things elegantly simple: Keep on thinking what is practically and pragmatically "enough" and "simple" for your own context than to try and cater for every possible scenario or corner case in a document that no-one reads. Deal with the exceptions as they arise.
Incubating the Future Now
9 年I really like this approach
QA Test Analyst
9 年Very interesting, informative and thought-provoking concerning testing.