With the emergence of software development methodologies like Agile, which values working software over comprehensive documentation, the software tester’s around the world started looking for leaner ways to create documentation. Furthermore, they started to question the value of lengthy documents like test plans. Tester’s felt that creating a test plan is time-intensive, tedious, and sometimes may delay the actual testing as well. The bulky traditional test plan document was not flexible enough for changes or modifications. Stakeholders and peers also felt the pain in reviewing the test plan.
Tester’s started preferring leaner alternatives like mind maps. I personally have used mindmaps to create test plans and have also recommended using them in several conferences and articles. Mindmaps solve most of the problems with traditional test plans. Test plans using mind maps are easy to create as well as flexible to update and review. Modern mind mapping tools make it easy to accommodate changes.
Sample test plan using a mindmaps
However, there are some challenges with using mind maps as test plans:
- Though some business leaders appreciate the value of mind mapping. The majority of them feel that mindmaps are messy and unprofessional. Hence they may resist the radical change of using mind maps for test planning which can be discouraging for testers. This happens because of a lack of awareness about mind maps. It requires effort from the testing team to introduce mindmaps to their leaders and gradually roll them out to the organization.
- Mindmaps use keywords and phrases instead of long lines and sentences. This concise information sometimes can be misinterpreted by stakeholders. Large and poorly structured mindmaps can also be hard for the stakeholders to understand. Stakeholders’ attention spans decrease exponentially with their height on the corporate ladder. Test plans can make a difference only when your leaders read and understand them.
I recently read a blog by Clarie Reckless about the one-page test plan and was inspired to try it out in my organization. This insightful blog gave all the ideas to create an effective one-page test plan. I really liked the pdf-style usability test plan dashboard, which was inspired by the popular Business Model Canvas. However, I could not directly adopt it since it focused on usability testing. I modified the template to make it suitable for testing and meet the needs of my team and organization. I found that this test plan template solved some challenges that mind maps could not.
You can download this template for free from my website. It’s in PDF format with editable fields which are scrollable, so you can type straight into it. This template can be easily shared and reused. It’s issued under a One under a Creative Commons Attribution-ShareAlike 4.0 International License. Feel free to modify it and use it according to the needs and context of your project.
Why use a standardized test plan template?
Since the traditional style of lengthy test planning does not fit in the Agile/DevOps era majority of the testers have stopped creating test plans. I have observed that testers are directly jumping into writing test cases, or they start testing the application without a clear thought process or a testing strategy. The test plan is a great way to communicate with your team and the stakeholders about how you will approach testing a certain feature.
A test plan template makes testers think about the software testing scope, activities, risks, assumptions, impact, dependencies, schedule, environment, etc. This template will guide your thinking and make you think about the key aspects related to testing beforehand.
A test plan should be the first artifact that a tester should ideally create by shifting left as early as possible during the development life cycle. A test plan can be created at the start of a sprint or a project. Below is the structure of the template and what it means. Most of the sections are self-explanatory if you have created a test plan before.
The top section has the following components:
- Product
Type the name of the feature/module/product under test.
- Author
The name of the author of the test plan has to be entered in this field. Multiple names can be entered if there is more than one author.
- Reviewed by
Names of the reviewers who reviewed the test plan. I often observe that we forget to get our artifacts reviewed by our peers and leaders. This field reminds you not to skip the review process.
- Date
Enter the date when the test plan was created.
The main section of the canvas has the following components:
Product
- What are the business goals of the product?
As a tester, first, understand what problems we are trying to solve by building this feature/product. This helps you validate if the feature, when developed, meets or exceeds the expectations of users and businesses.
- What are the objectives of testing?
Understand the objectives of testing. Most of the time the objectives of testing are to find/prevent bugs and provide information about the quality of the product to facilitate decision making.
Roles and responsibilities
- Who is involved in testing?
- What are their responsibilities?
Name the team members and the responsibilities assigned to them during the project. This ensures that the team is on the same page about their roles and responsibilities. This assists testing leaders to allocate the right people for the project/release/sprint with the right responsibilities.
Impact areas
Talk to your developers and understand the areas that might be impacted due to these new code changes. Additionally, use your past experiences to figure out what areas could be impacted due to the new feature. I have observed that bugs get leaked to production as developers and testers fail or miss to identify impact areas due to the change.
Environment, Tools, and deliverables
– Which environments will you test?
Staging/QA/Pre prod/prod etc
– What tools will you use?
List of tools that will be used to assist testing.
– What are our deliverables?
Various artifacts that you will share with stakeholders like test plans, test cases, test case execution, test summary report, etc.
In-Scope and Not in Scope
What is the scope of testing?
What is not in the scope of testing?
As tester’s, we should identify and communicate clearly what is in the scope of testing and what is not. For instance, if you are planning to test only one most used browser like chrome(for whatever reason). Say that cross-browser testing is not in the scope of testing.
What are the planned testing tasks?
Mention all the tasks that you plan to conduct as part of your testing efforts. Mention the testing types.
Schedules/Test phases/Milestones
Stakeholders are always keen to know about the deadlines of the project. Share important milestones/test phases along with a tentative date.
What are the risks and assumptions?
- Think of the risks that may affect your testing and also plan strategies to mitigate the risks. For instance, highlight the areas that have a testability problem.
- List dependencies, if any. For instance, reliance on other teams for a certain task to be completed before testing can start.
- List assumptions which if proven incorrect can pose a risk to your testing.
Conclusion
A one-page test plan template looks professional, presentable, and appeals to business leaders. It is also called a 10-minute test plan as it takes minimal time to create one. This template acts as a dashboard, making it easy for the management to analyze and review information. Sometimes testers can get carried away and provide way too many details in the test plan, which makes it difficult for the leaders to consume all the details. The standardized template ensures that your test plan contains only the key information that the business leaders want to know. A standardized test plan template drives consistency in your test planning process across the organization. Most importantly, it makes you think about key aspects of testing beforehand.
So what are you waiting for?
Download the template for free and try the one-page test plan. Let me know what you think in the comments.
