Test Plan Document - Manual Testing Free Training

Welcome to the Manual Testing Free Training series.

In the last tutorial, we talked about the testing techniques for e-commerce testing. Please refer to the following link to learn about e-commerce testing:

Testing techniques to test an e-commerce website

All right, in the previous tutorial, we talked about the Test plan. A test plan is a document detailing an approach to test a system (machine or software). It is the basis for testing any software or machine. The test plan describes important information about the test project and resources that will be used during testing efforts.

https://www.qaonlinetraining.com/test-case-test-plan-manual-testing-free-training/

Okay. So In this tutorial, we are going to talk about  Test plan template content. We divided the test plan into different points/sections:

1. Cover Page

This page is essential as it includes the Name of the Project for which the Test Plan is being created. Besides, it also contains short details about how the plan would work in the Project, along with the Author’s Name.

2. Document History Log / Revision History

This is one of the significant sections and ideally, this section should be present in every document. This section is used to keep the track of all the changes that happen in the Document during the project. Whenever you outline a Test Plan for the first time, you need to update the logs. This section should be an option to mention:

1. the dates on which the changes were made.

2. the Name of the Reviewer along with details of the Approver, who is responsible for reviewing and approving the changes respectively.

3. Every change should be associated with the version number along with a brief description of the changes.

3. Reference

This section describes the basis on which the Test Plan is being drafted. Every Test Plan has questions that need to be answered by the team members or stakeholders. This includes “How these questions have been answered, whether over the phone or via email or discussed in other meetings etc.”.

4. Introduction

This is the first section of the test plan and should contain information about the brief description/purpose of the test execution plan of a specific Project.

5. Scope of Testing

This section describes the scope of testing, which includes functional, and non-functional aspects of the application. It also mentions what all types of non-functional testing will be in scope. It focuses on the features that need to be tested and features that aren’t needed to be tested, along with the Entry and Exit criteria of Testing.

This section of the test plan will describe what type of test approach we are acquiring for the execution of the project. Is it manual testing or automation testing? For suitable reasons.

A test schedule includes the details of the project schedules, such as the start date and end date. If we have a beta or alpha release mention schedule(s), that is also included in the test schedule. Apart from this,  a test schedule includes the testing steps or tasks.

(Note) It is advised to include buffer time in the schedules so that unexpected events can be handled in time.

This section of the test plan mentions the details of the type of test methodology that is used to validate the system/application/product. This includes a brief description of the Methodology adopted, along with the suitable reasons why we have chosen the method regarding the project/product. The following are the most frequently used test methodologies:

a) Black box testing methodology

b) Gray box testing methodology

c) White Box testing methodology.

12. Requirements/features to be tested

List out the features/requirements of the system/product/application that are to be tested. It includes a detailed list module-wise (If available).

(Note) represent the data in a tabular format with use case ID, SRS ID, and test case’s ID. This makes an easy to readability.

List out the features/requirements of the System/product/application that are not to be tested because of various reasons like

a) Non-accessibility of environment or different software(s).

b) Any specific feature(s) or functionality that is not yet implemented in the Current Build, etc.

14. Assumptions

List out the possible assumptions for the project in this section like

a) It is assumed that the test environment is properly configured and specific to that project only, which will not be used for any other purpose

b) Development environment will be separate from QA’s test environment

c) Development team releases testable software to the testing team on schedule etc.

15. Suspension / Exit Criteria

If any defects are found that badly impact the test progress, then the QA manager may choose to suspend testing. Criteria that will confirm test suspension are:

• Hardware/software is not available at the times indicated in the project schedule.
• When source code contains one or more critical defects, which seriously prevents or limits testing progress.

16. Resumption Criteria

Resumption will only occur when the problem(s) that reasoned the suspension has been resolved. When a critical defect is the origin of the suspension, the “FIX” must be verified by the testing team before testing is resumed.

All right !!! In the next tutorial, we will talk about the types of the Test plan.

To check other stuff in this series, please refer to the following link: