What is Test Planning in STLC?

Test planning is the second step in the software testing life cycle. It involves activities that lead to the creation of a test plan. The test plan is a document, typically written by a test manager or lead, that defines the scope, objective, risks, and approach for testing. The team will then reference the document throughout the project’s life cycle.

Why do we need this step?

Test planning is arguably the most important step in the Software Testing Life Cycle (STLC). Without a test plan, teams are in danger of losing their ability to stay focused or on track, and testers would have to refer constantly to their best judgment if an issue is out of scope. Also, there would be no documentation of risks which could cause further confusion later on. Essentially, the test plan holds the team accountable for their commitments.

Test Plan vs Test Cases

The term ‘test plan’ is thrown around a lot within the technology industry. There are stories of testers being asked for their test plan by product owners who, in reality, just wanted to see the test cases or test results. Likewise, it’s not unknown for management to request a test plan for the company when they actually meant a test policy. So where does the test plan fit in, and why do we need to perform test planning activities?

The old saying, ‘proper planning prevents poor performance,’ is perfectly relatable to test planning. A test plan is more than a set of test cases. It is a document specific to a project that defines the testing intentions for that project. A test team needs a test plan to communicate expectations throughout a project’s life cycle. A test plan supplies testers with definitions of what to provide and when and also gives product owners expectations for what the test team can deliver. The best test plans are written when test planning activities are performed thoroughly.

Steps for Test Planning in STLC

Step 1 – Gather

The first step for test planning in STLC is to gather your documentation and other information from your requirement analysis sessions. If your company has a test policy or test strategy, you should also have those available for reference. Another good thing to have is a list of Subject Matter Experts (SMEs). This way, as you are working and come across something that needs clarification, you will know who to contact quickly.

Step 2 – Define

Next, you will want to set some boundaries by defining the testing scope. This step is essential for testers to determine because then the project team knows what is expected of the testing team.

• Scope – What items are in and out of scope for this project? Or, in other words, what will or will not be tested? Sometimes a project may rely on a third-party system. In these cases, knowing if integration testing is expected or if that system is out of scope is essential. If an item is out-of-scope, it’s important to communicate this with the team so everyone knows not to test it.
• Objectives – What are the overall objectives of testing? For example, if the project involves testing financial reports, one objective would be to ensure accuracy. If the system is unstable, other objectives may be to find failures and defects. One test plan can list multiple objectives to achieve.
• Risk – It’s important to consider if any risks are involved. If so, how are they defined? If a feature is out of scope, it might be regarded as a risk. Likewise, if the project is on a tight schedule, and one of the test team members has upcoming leave, that too can be considered a risk.
• Approach – Testers will want to define a test approach and ensure the team receives the communication. If anticipation of failure is high, the team may want to take a risk-based approach to first focus on finding critical failures. A risk-based approach will require more planning time with the stakeholders to prioritize items. If the project involves some form of compliance testing, the test team may want to use a standard-compliant approach, which may require training for the testers to understand compliance rules.

Step 3 – Schedule and Budget

Scheduling and budgeting can be one of the more difficult steps of test planning in STLC. Scheduling test deliverables involves considering available resources so code is delivered on schedule. The schedule will assume blockers are resolved in a timely manner, along with other factors that depend on outside forces. For example, when someone gets sick and needs to take leave, code gets deployed late, or any other issue that is out of the tester’s control, it can cause the schedule to get disrupted entirely.

Likewise, attempting to budget can be frustrating. Sometimes projects are based on funding from other departments. When a project has a budget for two testers, but funding doesn’t arrive in time, the project may only be able to afford one tester. Situations like this can disrupt the schedule and test plan. These are valid frustrations, but they still need to be handled professionally and quickly.

Step 4 – Configuration Management

Configuration management is an activity that considers the relationship between the system’s integrity and the testware. During configuration management, test items and testware should both be identified and have a form of version control so bidirectional traceability can be determined between the two.

Step 5 – Select metrics

Metrics should be defined in test planning so testing progress can be monitored and controlled throughout the process. The metrics selected may include:

• Percentage of planned work completed – This will include test cases that have passed, failed, blocked, or are still to be run. Use these statuses to compare against any outstanding work. Doing this allows the team to evaluate if they are on track or need to give attention to a specific area.
• Defects reported – This is an often requested metric, although it can be misleading as a stat. Someone can find several spelling errors and register each one as a defect. Someone else may lump them together if they are in the same code section. A better metric is to report the critical defects that remain to be solved. When management asks if the project has a lot of bugs, testers can respond, “We found 100 bugs” or “We have three outstanding critical defects that need to be addressed.” The second response provides more valuable information that management needs to make decisions.
• Test coverage completed – Reporting the amount of test coverage could include unit, integration, system, white and black box, and functional and non-functional tests. Providing different types of testing on different levels can build more confidence in the system’s success.

Step 6 – Create the test plan

Lastly, after completing the above steps, you will want to document and formalize the test plan into something cohesive and easy to follow. Some companies use a template to maintain consistency throughout all projects.

Tips for Success

• Flexibility – As issues arise throughout the project, remember to remain flexible and adapt. The test plan may need to be updated as the project moves along. Avoid getting frustrated with changes. Instead, adjust your test plan for success.
• Know the project – While the steps to create a test plan are typically the same, not all plans contain the same information. Therefore, it’s essential to document the specifics of each project to provide the deliverables you have committed to.
• Test planning takes practice – Test planning can seem like a difficult step, but it’s vital to the STLC. But try not to become overwhelmed with test planning; the more you perform the test planning activities, the easier it becomes.

Conclusion

Although test planning can be tedious, it is an essential step in the STLC. Its activities involve a lot of communication with other stakeholders. Therefore, creating a test plan that communicates to testers and stakeholders what should be delivered is vital. This communication prevents misunderstandings and provides clarity into test deliverables.