I have worked on several software and hardware products over my QA career, including creating test plans for these products. The elaboration of test plans can be daunting, and the responsibilities may be unclear. In this blog post, I will help you prepare a test plan and who should contribute to it.
Usually, a test manager or test engineer will be responsible for writing the test plan and may collaborate with other engineers and project stakeholders. A test plan documents how your company will execute a test strategy. The testing strategy and product requirements are the basis for working on a test plan.
But what if you have a small team and maybe don’t even have any test engineers? In this case, a test strategy document may not exist, and it may be unclear who is responsible for preparing the test plan.
In the following sections, I’ll attempt to detail the process for preparing a test plan and who should be involved.
What A Test Plan Should Include
A test plan should help you build a quality product, and it should fit your project or company’s needs. You may work at a big company that follows or require industry standards, or you work on a startup with no testing process and need the essentials for guaranteeing product quality.
Let’s imagine a simple example; you are investing in building a website for an online store. You documented the requirements and use cases, had a design team design the website screens, and hired developers to develop the website. You made a significant investment to build your application and stock up on products to sell, so the launch must go smoothly. What additional steps would you take to guarantee a smooth launch?
Even if you inexperienced in testing, some of the steps you may think of are probably similar to the following:
- When does the site need to be ready and tested? (testing schedule)
- What do I need to test? (scope of testing)
- Who will test the website? (testing resources)
- What functionalities are critical, and what are my standards for launching? (acceptance criteria)
- How will you test the website before going live? (test environment)
The items above are some of the questions the test plan should answer and are similar to the definition of a test plan in the International Software Testing Qualifications Board (ISTQB) Glossary
A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.
Source: https://glossary.istqb.org/en/term/test-plan-3
What Are The Steps Involved In A Test Plan?
Let’s go into detail about the main steps needed for a test plan.
Scope Of Work For Testing
The test plan should include a clear scope of work so that everyone is aware of what is being tested. The work scope should consist of what will be tested and what features are out of scope for each test phase.
As an example, let’s imagine a test a purchase journey scenario. A customer visiting your website should be able to browse a catalog of items, add items to a shopping cart, checkout, review the shopping cart, and pay for the purchase.
Depending on your project phase, you may not have an entire product catalog set up yet; you may be using fictitious products with dummy images and product descriptions. For dummy product images and descriptions, you don’t want testers raising defects. You should state that product images and descriptions are out of scope.
On the other hand, you may be working on a future feature to add to your website after the launch. The testing scope should indicate out of scope features that are not ready for testing at this phase.
Another typical example is browser versions. You may, or may not, want to support older browser versions. A list of supported browsers and versions that must be tested should be included in the work scope.
Test Schedule In A Test Plan
A test schedule outlines the targeted milestones for project delivery, including the start and end dates of each testing phase and stakeholder responsibilities. Other relevant milestones may be included in a test schedule, such as defect triage meetings or Go-no-Go meeting dates, to decide if all stakeholders approve the product or if you must add another bug fixing and test cycle.
Planning the test phases will help you estimate resources and schedule to target delivery milestones. The first phase could be writing the test cases or test scripts for the test plan. It is also common to plan for various test cycles as each test cycle will raise defects that may need to be fixed. You won’t know how many bugs will be presented, so guessing the correct number of test cycles is tricky and may not be the same for everyone. From my experience, I find that two or three test cycles will do the job.
Resource Allocation In A Test Plan
Executing the test plan will require testers; you should include the resource estimation and planning in the test plan. The number of resources needed for testing will vary significantly between different projects or companies. In some cases, you may be limited to the number of tester resources available. In this case, you will need to tweak the milestones to allow more time for testing or limit the scope of work and number of test cases to what is realistically achievable. Focus on testing the most critical functionalities and outline resource and project delay risks when they exist.
Acceptance Criteria In A Test Plan
Defining acceptance criteria at an early stage helps everyone have a better view of the project status and to make the right decisions on the next steps.
In test cases, the acceptance criteria are the expected outcome of the test. When designing test cases, the desired result for success should be made clear. For each test step, you can include a description and expected outcome.
For a test cycle, the acceptance criteria may include a set of mandatory test cases passing, a minimum percentage of passed testcases, and a threshold for minor medium or critical defects. For product launches or important releases, or when releasing new features, you can do the final sign-off with a Go-no-Go meeting to discuss the test results and existing issues with all the stakeholders. In this case, the acceptance criteria may be the Go-noGo sign off from a set of stakeholders.
Planning The Test Environment
The test environment is where the testing will take place and the test cases executed. The test environment should be a close replica of your production environment so that you are confident your product’s behavior will be the same once it is deployed in production.
The test plan should include a description of the test environment and setup. Your company may have several testing environment setups, and you want to make sure everyone is testing the correct software version on the configuration prepared in the plan.
Who Should Write The Test Plan?
In this post, we have gone through the main steps of a test plan. The test plan includes information gathered from different stakeholders, from setting up environments for testing, writing test cases, preparing test data, defining acceptance criteria, resource planning, allocation, etc.
The responsibility of writing a test plan should go to someone with a broad knowledge of the product requirements and the development process. In most cases, this will be a test manager or test team.
What if you don’t have a test manager? In this case, you have to decide who in your team is best suited to take on this responsibility. A test plan can be a collaborative effort where several team members contribute to the sections they are most knowledgeable about.
