In this series, we will examine the role of a software test plan, its mission in relation to our projects, refute resistance to its development, its components of it, and how to implement one.
Test Plan Overview
Creating a software test plan is one of the most fundamental principles and building blocks in software testing. But, with the advent of streamlined life cycle processes, such as Agile and DevOps, it has become a forgotten principle. The idea of committing the time and resources to the creation of test plans and other forms of test documentation is often minimized or ignored altogether. This is an unfortunate turn of events because there is tremendous value in a test plan that can greatly benefit all projects, regardless of the lifecycle.
Test Plan Resistance
It is not an uncommon occurrence to hear QA testers and QA managers quoted as saying things like “We don’t create test plans because we’ve implemented Agile” or, the statement “We don’t have enough time for test plans.” The reality is that no matter the lifecycle approach that you have implemented, a test plan is the most valuable tool in your arsenal to guarantee that the right resources are in a position to meet your test objectives.
Test Plan Mission
We should view our test plan as a project plan expressly for your testing process. In other words, it should n convey how QA testing will be performed at a specific level (ie. system testing or user acceptance testing), or for a particular type of testing (ie. stress testing, performance testing or security testing).
Our Test Plan can be seen as the granular instruction guide for all of our team’s testing efforts. The plan will describe the clear objectives of testing (ie. functionality we are planning to verify and/or validate), the precise scope of testing (what will/will not be included), combined with the general and sometimes detailed schedule of the activities you want to perform (ie. how and when we are testing).
One of the critical components (and often overlooked) aspects of our plan should be the consideration and probability of risk. It should list all of the foreseen risks inherent in the project and detail their respective levels. This allows us to prioritize our testing by these risk levels.
Perhaps the most important part of a test plan is the definition of resources needed. Resources can be seen as human (such as the people involved in the test) and technical (such as test environments, test tools, and test data).