An experience-based explanation of Test Plans with real examples
When building anything new, whether it’s a house, a car, or even a software application, we want to make sure it works properly and meets all the requirements. In all the cases you would probably want to create a plan before moving to the actual progress. In the IT world, project plans are one of the most important aspects of the entire SDLC, cause they represent the fundamentals of product success.
I have had the privilege of working in different outsourcing companies, where I had the opportunity to be part of software development teams that created products from scratch or enhanced already existing ones. In both cases the presence of a test plan allowed us to establish a common sense of our testing objectives, critical features, resources, procedures, risks, ways of working, etc.
What is a Test Plan?
In simple words, a Test Plan is like a step-by-step guide to making sure that whatever we create is checked and double-checked for quality. It’s like having a checklist to confirm that everything is in order before we launch or release our creation.
Imagine you have to build your house, and before doing so, you need to document all the related aspects, including the main development stages, approaches, resources, schedule, and acceptance criteria. Similarly, in our case, we are talking about a plan which consists of testing-related aspects that, once completed, will ensure that we are building the correct product from a quality perspective.
Why it is important to have a test plan?
As Douglas McGregor said ”An objective without a plan is a dream”
It’s impossible to build Buckingham Palace using resources meant for a typical house or to win an F1 race by riding a bike. The same applies to software product quality, which can only be achieved by having a realistic, thoroughly reviewed, and approved test plan.
Product Quality is the most important factor that will determine whether our customers choose the product we build. Therefore, the main reason for creating a test plan is to have a clear road map for achieving the quality deliverables that will generate the wanted project outcomes.
Moreover, the test plan plays a critical role in onboarding new QA Engineers within the product development team. A few years ago, when I joined an ongoing project, I was pleasantly surprised to find a rich documentation source in the existing test plan. Typically, test managers or more experienced QA Engineers write the test plan, starting with the solution discovery phase, and utilize it to establish clear directions, guidelines, standards, roles, responsibilities, and collaboration principles. I consider these details a must-have for building high-quality products, especially when more than 5 QA Engineers are involved, as it aids in ensuring synchronization among the team members.
During my career, I have had more than 10 interview sessions, and in more than 5 of them, I was asked when I finish the testing. Guess what? The answer to this question is team-dependent, and it has to be specified within the Exit Criteria section of a test plan. This section allows the involved parties to evaluate and determine if the testing objectives were achieved or if any additional activities are required to conclude the testing process.
What to do before you start writing a Test Plan?
For a quality and useful Test Plan, I usually review once again all the testing principles specified in the ISTQB Foundation Level. No matter the project domain area I am working on, I am sure that following up on all the principles helps me to get more creative ideas that I can apply during the solution discovery phase.
For example, early testing saves time and money. To ensure we adhere to this principle, I would review the allocated resources and explore how they could be invested to initiate testing as soon as pieces of SRS (Software Requirement Specifications) become available. I would determine the best practices for static testing to thoroughly review the requirements, providing developers with well-refined details and preventing bugs from arising.
A preventive approach is one of the most efficient ways to save money, safeguard mental health, and optimize team capacity. By catching and addressing issues early in the development process, we can avoid costly rework, reduce stress, and ensure the team’s productivity remains high. And this can be designed as part of the Test Plan content.
Another example would serve the principle of context-dependent testing, this is why as a Test Manager I have to understand the product business flow and explain it in simple words as part of the Test Plan. Knowing the business challenges and critical features that will be tested allows me to efficiently underline the smoke and regression testing flows, and decide on a knowledge-sharing strategy.
Integrating testing principles into the test plan creation procedure is indeed a valuable topic for your future articles. Establishing the level of responsibility in correspondence to the Test Plan is crucial for ensuring clarity, accountability, and successful test execution.
What is my responsibility in regard to Test Plan?
If this is a question you ask yourself, then I would suggest carefully reviewing the below roles and related activities.
- The test Plan Owner is typically the QA Manager or Lead QA Engineer (Senior QA), who will be responsible for the overall creation, maintenance, and approval of the Test Plan. This individual ensures that the Test Plan aligns with project objectives, standards, and testing principles.
- Test Team Members’ responsibility is specified in the test plan section called Roles and Responsibilities. Usually, I specify and assign specific responsibilities for tasks such as test case creation, execution, defect reporting, and documentation. All the team members, including me as test plan owner are responsible and accountable for completing the test plan and accomplishing the exit criteria.
- The project manager is usually responsible for the overall project's success, including quality direction too. Therefore, the PM will be responsible for carefully reviewing the test plan, and approve after engaging the stakeholders and collecting their feedback.
The details above are provided based on my real-world experience and could differ from some particular cases, however, I found them as good practices and would encourage you to create your own section of Roles and responsibilities when writing your Test Plan.
To sum up
A Test Plan is like a guide that helps us make sure the software we build works well and meets the requirements. It’s important because it ensures product quality and set up a great base for team collaboration and common sense.
I’ll cover the other sections of a Test Plan in my next article, which will help you create effective plans for your projects.
