Test strategy document problems
In the old days of waterfall, we were extensive on documentation and had hefty test strategy documents as well. Traditional test strategy documents used to have mountains of information, a lot of which wasn’t really used practically. They were all great writing in theory but hardly followed.
As agile came along, many teams started to pivot towards not writing a test strategy at all. Perhaps one assumption was being agile means no documentation. This never sit right with me and wasn’t happy with the approach. Ever felt like you have a lot of ideas in your head, but since can’t see them on paper, your sixth sense keep’s telling you ‘I’m missing something’, that’s what it was.
What was needed
Having no test strategy document, important ingredients to bake quality into the products was difficult. So to me it was always clear we needed a test strategy, but having done the old school test strategy documents, I knew something like that was of no use either.
I started listing what I’d like an ideal test strategy document to be like. It should help with:
- Defining the direction and vision of testing
- Consolidate quality related attributes we need to consider
- What to focus on testing, where in the tech stack & how?
- What to automate and how?
- Some practices / references engineers can refer to in day to day practice
These would give the whole team a sense of alignment towards a common goal, vital to bake quality into the product and not try to ‘gauge’ after the fact.
DevOps Test strategy
After transforming team’s quality practices for a while, I noticed certain things which I kept on preaching to most team and end up writing them in some shape or form. Meanwhile a dire need of a good training program was needed as well to train engineers on testing and automation practices. While designing the program I saw a perfect opportunity to design a course for building a test strategy for agile teams, and that’s when I came up with the “DevOps Test Strategy Mindmap”.
The mind map depicts the target state for common web applications running in an enterprise and how to plan your quality practices to get there. The purpose was to give teams a sample target state and develop one according which suits the team’s needs.
An important aspect of this test strategy was it should be easy to update and maintain. I love mind maps the most among all the different documenting techniques I’ve used, therefore made one for the test strategy. It helps to keep it:
- Concise – To the point information
- Complete – Covering important areas teams transforming into DevOps ways of working should consider
- Easy to read & maintain – In the form of a mind map so readers can see the whole landscape at once
To get the high-resolution version, click here:
I hope you find It useful for your teams. Feel free to share your experience about it in the comments.