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.
In my article published on TestRail blog, I talk about four useful 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.