Great test planning

Test planning and writing Test Plans can increasingly be seen as a waste of time, especially in agile teams. However, there is still a strong case for the practice and it's a tool I continually come back to.

When is a test plan not useful? Well, when it's full of generic and non-specific information. Test plans that are pages long and have copy/pasted sections that were in every other previous test plan. If this repeated information is useful for your team, definitely capture that so it can be referred to, but don't repeat it in every test plan as it could hide away the good stuff.

Consider situating test plans in the same space as other technical artefacts and plans, rather than stand-alone documents. WIKI’s or SharePoint sites are great for this. Link out to other relevant areas and keep the document alive throughout the time it’s applicable, updating it when necessary.

What are useful things to include in your test planning? Here are my top 5 things to cover. It's not an exhaustive list but a solid starting point for things you should have in place to deliver your testing activities.

1)    Environments

If you don't have suitable environments to run your tests, you will be delayed and on the back foot from the start. Your environment needs may progress over time but to be effective what do you need initially? If it's a web-based application, try to actually write down the URL you intend to use for each of your testing phases. Similarly for apps or installed applications, what versions for testing will you require, and against what backends? This helps ensure alignment between others using the environment, the budget for providing the right amount of environments and the suitability of the environment for the testing being done. If testing integrated systems or applications, make sure you have the correct integrations in place. If these are run by third parties having contact details in place can be useful.

2)    Data
What data do you need for the tests you want to run? Do you need seeded databases with specific types of data? Do you need a stock of unique data that can only be used in one test? Do you need specific account types and do they need any historic activity to run a particular test? Who will be responsible for creating and maintaining the data? Will any automated processes be run for creating the data? Does any data need to be encrypted or obfuscated? Do other teams need data?
Missing correct, clean data to run a test can result in delays, troubleshooting the wrong issues or even missing potential defects. It's worth investing the time to think about your data and have clarity about these questions.

3)    Scope
Defining the edges of your scope is useful at this early planning stage. I find creating a mind map the best way to illustrate what is understood to be the functional areas required to be tested. You can use a tool like www.app.mindmup.com. This often prompts the tester to gain clarity around certain items and what is within the testing scope. The mind map is a good way to review with others and provides an opportunity to question any different understandings and provide alignment from the start. As a basic illustration of what your mind map might cover:

Example scope mind map

4)    Test phases
Include the types of testing and when you intend to carry out a test phase. In larger programmes, this can help ensure clarity between teams and remove any duplicated activities. It also helps when specific test activities are needed, for example, you may want to run a performance test in each sprint. If a penetration test is required, this might be closer to going live when the most representative code base is available.

5)    Sharing

Share your test plan! I would always recommend a run-through of the plan with the team. This doesn't have to be long-winded, just a collective review to show what the testing goals and intentions are. It gives wider visibility and an opportunity to tease out any areas that might have differing opinions. If the information is concise and relevant, it's a great point for the delivery team to collectively agree on something. And it's a great way of getting people to understand the value the test team are adding.