This is a guest post by Nishi Grover Garg.
Planning is an integral part of initiating any project or activity, including software testing. Although formal test plans may seem outdated and unnecessary to most fast-paced agile teams that prioritize cutting down on documentation, it’s still a good idea to keep a pared-down test plan that can guide the testing effort throughout the project.
Here are four tips to create a simplified test plan for your agile project.
1. Include the basics
A test plan can be as detailed as the team requires, but at the minimum, it must contain the context, timelines, and a brief overview of the testing activities expected to be performed in the project, release, or sprint.
Based on what level of test plan you are creating, begin with a basic heading, like schedule and timelines, testing activities and types of testing expected to be performed, people involved in testing, or any new hires or training required for the project or release.
2. Build off the project plan
Most of the test plan can be derived from the context set by the overall project plan, so give that a thorough read and get the details of the project lifecycle, expected delivery schedule, interaction points with other teams, etc.
Note any specifics that emerge, like shared resources with other teams, sync points for integration tests throughout the project’s lifecycle, or special types of testing needed, like performance, load or security testing.
3. Define a clear scope
Let’s say your project is a mobile application that needs to work on both Android and iOS. It would be beneficial to list all the environments and OS versions that need to be supported. Including them in the test plan ensures you set up the test environments early and allocate testing tasks across all of them. It also ensures that you are not bogged down by repeated testing on numerous test environments at the time of release. What is not defined in the initial test plan can automatically be considered out of scope.
To that point, it is imperative to define “in-scope” and “out-of-scope” categories clearly in the test plan. Whatever is expected and intended to be done is in scope, like functional testing on all user stories, regression tests, sanity tests, a final user acceptance test, some performance and load tests on specific points of the application, and test case reviews.
Whatever is outsourced, left to third-party or other teams, or not included in scope can be safely ignored and not have any resources allocated to it. For instance, let’s say security tests for the entire software are outsourced to another company; then there would be no need to perform security tests on specific user stories. Similarly, supporting OS versions lower or older than the specified minimum would be out of scope for testing.
4. Use visual tools like mind maps
You can easily create test plans that are simple, minimalistic, and easy to read and understand by using mind maps. Gather the entire team, get the information needed from the project plan and from the respective stakeholders, and create a mind map in minutes describing your test objectives, approach, environments, schedule, tasks, budget, and test items.
Below is an example of a simplified, minimalist test plan created using a mind map, and you can read more to find out how to leverage mind maps to create your test plan.
These four tips can help you create a quick and simplified test plan to help guide your next test cycle.
