Top 10 Attributes Every Sample Test Plan Document Must Have

Let’s suppose, you want to create a test plan document for your web application, mobile or any other software. You search “sample test plan document” on the internet and come across numerous test plan samples.

By looking at the sample test plans, you understand that a software test plan document is a guide book for testing process. It is required for the successful execution of testing process for a project. It contains comprehensive information to carry out the testing activities.

A software test plan document is divided into different sections such as introduction, objectives, scope, test items, features to be tested, and environmental needs. There are several test plan samples, each with different sections.

Are you wondering what the 10 attributes every sample test plan document must have? No problem! We discuss them in detail here:

Introduction

A software test plan document begins with the introduction of the project and the product being tested. Include the following details in the introduction of your test plan:

• Project Background: Explain a brief overview of the project and its background.
• Purpose of Document: The purpose of test plan document is to provide details on how testing process will be conducted for a given project.
• Objectives and Tasks: This section contains your testing objectives and tasks.
• Scope: In this section of test plan document, the scope of testing is identified at high level. You might also need to explicitly mention some features which are out of scope.
• Test Items: List down the test items with release version and module details that are targeted for testing.
• References: In the references section of test plan document, list down the documents that are and can be referred to during execution of testing process.

Features to be tested

In this section of the test plan document, list down the features and functions in details that you have planned to test.

These features should fall under the testing scope which has already been identified in the introduction section.

For each feature to be tested, define the references of requirement with requirements ID so that the quality assurance team can refer to it. Describe any special consideration or details about the particular feature, if required.

Features not to be tested

There can be some features or functionalities which are neither clearly out of scope nor could be tested due to any reason.

These features should be mentioned in your software test plan document in the ‘Features not to be tested’ section. Also, define the reason why a certain feature or functionality cannot be tested.

Item Pass/Fail Criteria

Define the success criteria of your tests in the test plan document. You can encounter three situations while executing the test cases – normal, suspension, resumption.

Let us have a look at the item pass/fail criteria from a sample test plan document of web application:

• Suspension Criteria: Any situation which impedes the ability to continue testing or value in performing testing lead to suspend testing activities.
• Resumption Criteria: When the problem that caused the suspension had been resolved, testing activities can be resumed.
• Approval Criteria: An item will be considered as ‘Pass’ if it meets the ‘Expected Outcome’ defined in the corresponding test case.

Approach

Test approach is the backbone of the entire testing process. Hence, it is one of the important attribute that every test plan document has. In test approach, it is clearly stated what testing techniques will be applied during the testing process.

Your testing approach may combine more than one testing technique such as exploratory testing, functional testing, regression testing, user interface testing, component testing, integration testing, penetration testing.

Specify the tools and required human resource to perform the testing activity. The approach should be described in such a manner that major testing tasks could be identified.

You need to see ‘Features to be tested’ section to adequately define the testing approach in your test plan.

Test deliverables

At the end of every testing activity, there is a deliverable. Include the list of test deliverables in your test plan document. Test deliverables might include test plan document, test cases, issues report, and performance report.

 

Environmental Needs

Software test plan document contains details of the specifications needed to set up test environment. There can be hardware and software needs for your product.

Hardware Needs

Hardware needs might include the device specifications such as desktop computer, laptop, tablet PC, smartphone. It can also include a specific screen size, memory requirement or processor speed.

Moreover, there can be some requirement related to your internet connection – whether the device should have Wi-Fi or LAN connection, what should be the download and upload speed of your Internet.

You might also need extra hardware for requirements where you might need to simulate the load of concurrent users.

Software Needs

Software needs include the operating system specifications such as Windows, Mac, Linux or Android. There can be further detail of version for the operating system. If you are testing a web application, you need to list down the browsers in your test plan on which you will perform the testing.

You might need to use any tools or software to perform testing or to set up the test environment.

List down all required software and make sure you procure the required software on time so you can proceed with the testing process as per schedule.

Roles and Responsibilities

A test plan document contains resource requirements. It also contains details of roles and the associated responsibilities of the individuals.

If you have a big team, you can define roles and responsibilities in the form of a table. We are sharing ‘Roles and Responsibilities’ section from a sample test plan document:

S. No	Role	Responsibilities	Name
1	QA Manager	Review test cases, review and approve the issues
2	Senior SQA	Assigns tasks, tracks the testing progress
3	QA	Prepare test cases, set up test environment
4	Tester	Execute test cases, reports the issues

Schedule

A test plan document is a guide book to your testing process. Schedule is the essential attribute that defines the timelines for your testing activities. Make sure that you plan your schedule in accordance with the development schedule.

Remember that you cannot test a feature or module, unless it is developed. This develops a high dependency of quality assurance team over development team. If development team lags behind the schedule, your testing schedule will be badly disturbed.

It is recommended to isolate your testing activities and continue completion of your tasks, while the product is being developed. For example, you can gain business understanding and prepare test cases before any artefact is available for testing.

We have shared a schedule included in the sample test plan of web application. You might add or remove columns in the schedule table as needed.

S. No	Task	Dependency	Deliverable	Week
1	Business understanding			0-2
2	Prepare test cases	Task 1	Test cases	3-4
3	Execute test cases	Task 2		4-7
4	Report issues	Task 3	Issues log	4-7
5	Test fixes			8-9
6	Report the findings		Test report	10

Risks and Contingencies

Risk is the uncertainty which is associated with a future event which may or may not occur and a corresponding potential for loss. Being the project manager, it is very important that you identify the risks in your test plan.

Schedule Risk

Meeting the planned deadlines plays a vital role in the successful completion of a project.

Before you prepare your risk mitigation strategy, it is important to understand the reasons that increases the likelihood of risk occurrence.

You might lag behind your schedule because of any of the following reasons:

S. No	Risk	Mitigation Techniques
1	Inaccurate time and effort estimation	Use PERT techniques Use expert judgment techniques to assure the accuracy of estimates
2	Inability to foresee the total scope	Create work breakdown structure for your project Analyse the ‘Features to be tested’ thoroughly
3	Unexpected expansion of scope	Include contingencies in your schedule
4	Inability to complete tasks at the estimated time	Track the progress of individuals on daily basis Address any issues that are hindering the completion of tasks Train resources to upgrade their skill set Provide a realistic estimate while making schedule

Budget Risks

Budget is a crucial element in any project. It not only affects the success of your project, but it also affects your relationship with your client.

It is very important to control and mitigate any risks associated with budget to prevent any unpleasant happening that might strain your reputation.

The more accurate your budget is, the better your will be able to manage your project and stakeholders.

We have listed a few budget risks below:

S. No	Risk	Mitigation Techniques
1	Wrong estimation	Prepare a rough order magnitude estimate initially Prepare detailed budget estimate when tasks and activities are clearly defined
2	Resource budget over run	Track and control that resources do not take more than the planned time for completion of tasks
3	Cost overrun due to scope	Control the scope of the project Define a process for approval of ‘Change Requests’ along with their costs
4	Indirect costs	Include the estimates for overhead costs, general and administrative costs

Operational Risks

Operational risks are associated with the day to day activities of the project. Operational risks may eventually lead to improper process implementation or a failed system.

Operational activities are performed repetitively; this means that operational risks can be mitigated by following company’s standard procedures on regular basis.

Quality control team plays a vital role in overall improvement of the software development process.

While including operational risks in your test plan, consider the following risks:

S. No	Risk	Mitigation Techniques
1	Failure to address priority conflicts	Clearly prioritize the requirements with stakeholders Use adaptive planning approach to accommodate priorities
2	Insufficient resources	Control and track whether the project activities are progressing as planned
3	Insufficient resources	Estimate the required resources and procure them
4	No proper subject training	Conduct staff trainings if needed Use the right people for the job Outsource resources
5	No resource planning	Prepare human resource plan
6	No communication in team	Conduct staff trainings if needed Use the right people for the job Outsource resources

Technical Risks

Technical risks can still exist even if you have planned everything flawlessly. There is an increased likelihood of technical risks when the technology is new.

Other technical risks include the following:

S. No	Risk	Mitigation Techniques
1	Changing requirements	Use agile software development method
2	No advanced technology available or the existing technology is in initial stages	Conduct trainings to build expertise Build a relationship of trust with client and prepare his mind for the technological risks Give time, effort and budget estimate keeping this point in mind
3	Complex product	Use experienced people for the job with the required skill set Break the problem into smaller parts
4	Difficult integration of project modules	Perform impact analysis Exhaustively perform regression testing

Test Plan Example

Here is a sample test plan that gives a list of items you should include in your test plan.

• Introduction
• Objectives & Tasks
• Scope
• Test Strategy

1. Alpha Testing (Unit Testing)
2. System & Integration Testing
3. Performance & Stress Testing
4. User Acceptance Testing
5. Batch Testing
6. Automated Regression Testing
7. Beta Testing

• Hardware Requirements
• Environment Requirements
• Test Schedule
• Control Procedures
• Features to Be Tested
• Features Not to Be Tested
• Roles & Responsibilities
• Schedules
• Dependencies
• Risks/Assumptions
• Tools
• Approvals

Recap

Let’s have a quick review of what we have understood till now. We know a test plan document is vital for the successful execution, tracking and controlling of testing activities in a project. It contains all necessary information to guide the testing process.

A software test plan document is divided into various sections. We had a detailed look on the top 10 attributes every sample test plan document must have.

First part is the introduction which provides a brief overview of the project background, scope, testing objectives and references.

Then, we define a list of features that should be tested and the features that should not be tested, along with success criteria. This enables us to scheme a detailed testing approach for the identified features to be tested.

The output of testing activities is the test deliverables.

We also need to include any specific environmental needs to set up the test environment.

Moving on to the resource and task planning, we define the roles along with schedule of tasks.

Lastly, we include the important part of risks and contingencies.

Next time you make a test plan document, do not forget to include the top 10 attributes in your test plan document. If you know of other important attributes that should be included in a test plan, share them in the comments below.