Test Plan

Test Planning is not putting 2-3 things together, it’s a practice that QAs has to follow all the time for all projects or requirement.

Test Plan can be created once for whole project or individual requirement if the requirements need different plan for testing.

Topics Covered

• What is Test Plan?
• Why we do it?
• How to do the planning? What are the steps to do effective planning?

You’re developing a software, and you want your client’s experience with your software to be excellent, so you want proper testing of your software, and that needs proper planning, how the testing will be executed, what will be included, what’s not included, what are the steps.

As a testor, you first understand the Business Requirements Document that a Business Analyst has created out of Business Case. So this is the first step in how you’ll do the planning, without understanding what is going to be developed and having no idea about it, you’ll not be able to layout the plan, so that’s why your first step is to understand what is it that team or business is planning to build. And if you don’t have idea about what’s going to develop then ask the team for BRD.

Now, you’ve the BRD, so understand the BRD document, but what will you see in a BRD, what information is really important for you and what all things that you need to see to make a test plan, this is really important, because if something is not there or missing in BRD, you can ask the team early to provide that information to make the test plan successfully.

Check following in a BRD:

1. Business objectives & scope.
2. Functional requirements.
3. Key workflows & use cases.
4. Acceptance criteria.
5. Dependencies & acceptance.

When you receive the document first, check whether all these information are there in the document, and after that check whether the information is sufficient or need more clarity. In 1st point, you only need to check the whether all these sections of information exist in the document and in 2nd point you actually check the quality of the information. You can check the document you received right away for the sections existence and read it later in depth.

Requirements in BRD must be clear and well written before writing the test plan. BRD is the main requirement for Test Plan creation.

Business objectives & scope

Why do a QA need to check business objectives & scope? QAs need to know exact what is it that business is trying to achieve, and what all will be covered and what’s not covered. Testor will have an idea around the testing efforts required for the project completion, and resources alignment can be done early. But don’t understand in depth, do this only to understand the purpose and impact of the objective and scope.

Business Objective: Improve user registration accuracy by validating email and phone.

Scope: Add email & phone validation fields in registration API and form UI.

Business Objective: Enhance customer engagement through personalized dashboards.

Scope: Develop user-specific dashboard API and UI showing recent activities and recommendations.

For all this, BRD must be well written, it should have clear objective and scope of what are we going to do. If the BRD is unclear, incomplete, or even overly written then it’ll be hard for testor to plan the testing. So, BRD should be written in sufficient amount as required, neither over written, nor under written, just sufficient as required for the time being.

QAs test plan depends 50% on the BRD and remaining 50% on the capability of QA to foresee possible outcomes, providing feedback, understanding plan components, and planning, looking at them is a different concerns.

Functional Requirements

See how many functionalities are mentioned and discussed in BRD. If requirements says responsive design in mobile then it’s obvious that you need to plan testing for mobile devices as well, you need to think what all devices will be included in the testing. Check whether the BRD mentioned any constraint on devices that application will be used, and your responsibility is to plan the responsive design accordingly included in plan, resources aligned as per requirements. Project’s success will depend on requirements clarity, development, proper alignment of resources and planning, so basically everyone plays a crucial role on project success, and QAs role is to provide proper plan and execution of testing.

Key Workflows & Use Cases

Workflows will give you understanding how the complete flow will work, each flow will denote an activity done by user and it consists of various steps in a flow, and as a testor you need to add flow testing in your test plan. Registration, logon, form submission, data update are few flows that are done by users, and you will test the same so plan the testing of same, include the efforts estimate of these testings as well, distribute the responsibility like flow testing by 1 testor, and individual feature testing by another testor. Separate API testing and workflow testing.

If workflows information is not there in BRD, you should ask the team to define different workflows and use cases, without this information you won’t be able to plan testing, and the coverage will be limited and there will be a defect that will be skipped in our testing and released till production, let’s call them skipped defects.

Checklist

1. Get the BRD and understand it.