Think of test planning like raising children. Let them loose and you’ll soon find yourself scolding them. Explain what behaviors are or aren’t okay and they know the boundaries they're playing in (or pushing).
As with children, so it is for QA: correcting course by changing habits later on is much harder than setting a framework from the start.
Your test plan is this framework. It’s a philosophy with guiding principles that tell your team how dynamic (or not) they can be. From this they can build muscle memory and accelerate their testing with each iteration. This means more efficient test cycles, without the need to course-correct.
Let’s discuss how to write a test plan that works for your project.
Creating the right test plan
In our experience, as in so many walks of QA, proper test planning comes down to quality questioning. Getting to the heart of the answers to the following questions allows you to build more than a list of pre-requisites and targets (as important as they are). Armed with team-informed input, you can create a true QA roadmap or test plan.
What will people tell you?
What are you testing? Who is building it? Why are they building it? These are fundamental questions but the value is in how you get the answers, rather than what the answers are. The how is crucial and gives you really important insight.
If the dev team seem quiet and your testing team don’t contribute much to the discussion then it will be harder for you to delegate in the project. It means your test plan will have to be more prescriptive and include significant oversight.
If you’re looking for a more hands-off approach, then choose testers who have opinions and enjoy sharing them with you and each other. Build connections with the development team. Show an interest in what they’re developing and tell them why you want to know.
Fostering strong relationships helps you build a test plan that’s both detailed and dynamic. This in turn empowers your team to get creative.
What scope do you have?
How risk tolerant are your stakeholders? Do they believe if the testing approach worked last time, it will work this time? Or are they looking to try something new?
If your stakeholders veer towards the conservative, your plan will be more prescriptive. This will suit focused, detail-oriented team members who excel at rote-based tasks.
If your stakeholders are more creative, they won’t need every specificity nailed down in the test plan. This opens up possibilities for more dynamic testing and more creative team members.
What kind of team do you already have?
Who’s on your team and what are their strengths? How do your team members interact with each other? Foster collaboration to limit slow resolutions and more conversation.
When setting boundaries for children, any parent, aunt or babysitter will know that you have to make some allowances for the child’s personality for boundaries to work.
Some testers will suit dynamic environments but might require guidance when it comes to collaboration to ensure they don’t run away with an idea on their own. Detailed-oriented testers who thrive on the predictability of rote tasks might get frustrated when things aren’t going exactly to plan. Here, your test plan would include guidance on how to raise concerns and who to raise them with.
The test plan guides your team, but your team should inform the guidelines you provide.
Time to write your test plan
With these answers and insights you can tailor your test plan to your product, project and people. You can also define your own role: be it liaison, hands-on manager or advisory leader encouraging direct communication between testers and devs.
Defining your pre-requisites and setting targets to give your team focus is vital. But it’s not enough. Developing a truly useful test plan requires extra effort upfront. And as coach John Wooden said:
“If you don’t have time to do it right, when will you have time to do it again?”
After reading this, you may decide you would like a conversation with us. OnPath would be happy to provide direction for your testing style and your test plan. Reach out if you want to talk it out.
Test plan vs test case (and why you need both)
Poor software doesn’t provide value to users. It causes customers to complain, cancel...
The benefits and types of automated testing you need to know about
Why dig a hole with a shovel when you can use a backhoe?