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:
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.
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.
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.”.
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.
This includes a detailed list of the environment(s) on which the test setup has to be created. It also includes each OS & software(s) along with its version(s) and patch(s). (Note) any specific test cases, those are specific to OS or software(s). Give the total number of such specific test cases in a tabular format (if applicable)
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.
The resources section includes the Hardware, software(s) requirements, and the manpower needed for the Project execution. (Note) do consider the budget allocation for that project, while requesting the hardware & software(s) and manpower. It also includes who is responsible for performing each activity and who will be the reviewer.
It is a list of all the documents, tools, and other components that have to be developed and maintained to support the testing effort. These documents are handed over by the team to the customer along with the product. It includes the following:
- Test plan
- Test Cases
- Test Scripts
- RTM(Requirement Traceability Matrix)
- Defect Report
- Test Execution Report
- Graphs and metrics
- Release Notes
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.
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.
It includes the possible risks for the project execution. They might be:
a) Testing the functionality of the product which is integrated with third-Party software.
b) Team is not properly trained on the technology on which the application is built and to be tested.
c) Execution of test cases in a shorter period of time due to deadlines etc.
There can be many other points that generally, every standard Test Plans have like Approvals, and Concepts procedures; however, we would like to believe that those would not be fit to be categorized as standard points. Moreover, the points could vary from one project to another project.
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:
Happy learning, until then!