A Test Plan is an elaborate document that describes the test approach, purpose, plan, estimation, results, and resources required for testing. It assists us in regulating the effort required to verify the quality of the application under test. The Test Plan acts as a layout to implement Software Testing activities as a defined process that is closely observed and supervised by the Test Manager.
Who Prepares the Test Plan Template?
The Test Lead or Test Manager prepares the Test Plan template. Testers are also involved in the procedure of writing test plan templates. After the test plan is written, the testers will write test scenarios and test cases depending on the test plan document.
Purpose of Test Plan
The key purpose of a Test Plan is to build documentation that defines how the tester will prove that the software works as it should.
- The document should detail what is required to be tested, how it will be tested, and who is in charge of testing.
- It acts as a layout to implement software testing activities as a defined process.
- By putting up a test plan, all team persons can work together and communicate their parts to each other.
How to Prepare an Effective Test Plan Template?
The following steps are to be considered for writing a good test plan template:
- Know about the product.
- Create a testing strategy.
- Describe the testing scope.
- Build a Test Environment.
- Identify the types of testing.
- Describe the objectives of testing.
- Estimate major dangers and defects.
- Define roles and responsibilities.
- Calculation and Schedule.
- Set up the Test Deliverables.
Test Plan Template Format
The below Test Plan template should be followed:
(Software’s name)
Prepared By:
(List of names who prepared this)
(Date)
1. Introduction
- 1.1 Test Plan Objectives
2. Scope
- 2.1 Data Entry
- 2.2 Reports File Transfer
- 2.3 File Transfer
- 2.4 Security
3. Test Strategy
- 3.1 System Test
- 3.2 Performance Test
- 3.3 Security Test
- 3.4 Automated Test
- 3.5 Stress and Volume Test
- 3.6 Recovery Test
- 3.7 Documentation Test
- 3.8 Beta Test
- 3.9 User Acceptance Test
4. Environment Requirements
- 4.1 Data Entry Workstations
- 4.2 Mainframe
5. Test Schedule
6. Control Procedures
- 6.1 Reviews
- 6.2 Bug Review Meetings
- Change Request
- Defect Reporting
7. Functions to be Tested
8. Resources and Responsibilities
- 8.1 Resources
- 8.2 Responsibilities
9. Deliverables
10. Suspension/ Exit Criteria
11. Resumption Criteria
12. Dependencies
- 12.1 Personal Dependencies
- 12.2 Software Dependencies
- 12.3 Hardware Dependencies
- 12.4 Test Data & Database
13. Risks
- 13.1 Schedule
- 13.2 Technical
- 13.3 Management
- 13.4 Personnel
- 13.5 Requirements
14. Tools
15. Documentation
16. Approvals
Below is the test plan template discussed in detail:
1. Introduction
It is a short synopsis of the software that is being tested, test strategies, procedures, the flow of work, and methods needed for the project. It highlights every function at a high level.
1.1. Test Plan Objectives
It describes all the purposes carried out by the Master Test Plan. It lists every task made by this test plan. List all the goals that you aim to finish with manual and automation testing. Some goals of testing your project can be:
- Make sure the Application Under Test satisfies functional and non-functional conditions.
- Make sure the AUT lives up to the quality conditions described by the client.
- Bugs or defects are found and fixed before going live.
2. Scope
Scope describes the modules and functional or non-functional components of the software that need to be tested. Out Of Scope describes the modules, functional or non-functional components of the software that need not be tested. This section defines what is to be tested, which feature is new to every function of a particular product, its current interfaces, and the interlinking of all functions.
Detail here on how you will finish the items that you have listed in this Scope part.
- 2.1. Data Entry: This is the process of inputting details into this test plan.
- 2.2. Reports File Transfer: The reports in the file transfer section are mentioned here.
- 2.3. File Transfer: Here files are transferred between two software. A file is moved or copied from one software to another software through a network.
- 2.4. Security: It describes whether the software is secure or not.
3. Test Strategy
- Define the whole technique for testing. For every important class of conditions or feature compounds, name the technique that will make sure that these condition compounds are tested enough.
- Name the important tasks, approaches, and testing tools that are needed to test the designed class of features.
- The techniques must be defined with adequate details to accept the recognition of the key testing keys and the calculation of the time needed to do all.
3.1. System Test
- Write what you know about system testing for the project.
- Name the persons who will be doing system testing on the project. Make a list of all the persons who are responsible for this testing.
- Define how to conduct system testing. Name the people who will write the test scripts for unit testing, what should be the series of events of the system testing, and how should be the testing task.
3.2. Performance Test
- Write your understanding of performance testing for the project.
- Name the people who will conduct performance testing on the project. Make a note of all the persons responsible for this task.
- Define how to conduct performance testing. Name the people who will write the test scripts, what should be the series of events of the performance testing, and how should be the testing task.
3.3. Security Test
- This is a procedure to find defects in the security application of an information system that secures data and manages functionality as required.
- Name the people who will conduct security testing on the project. Make a note of all the persons responsible for this task.
- Define how to conduct security testing. Name the people who will write the test scripts, what should be the series of events of the security testing, and how should be the testing task.
3.4. Automated Test
- This testing is the application of testing tools to automate a manual procedure of verifying and validating software.
- Name the people who will conduct automation testing on the project. Make a note of all the persons responsible for this testing.
3.5. Stress and Volume Test
- Stress testing is a type of performance testing that will happen when you push your app, API, or software to the higher limits of its capacity. Volume testing is a kind of software testing that is done to test a software application with a definite portion of data.
- Define how to conduct stress and volume testing. Name the people who will write the test scripts, what should be the series of events of the stress and volume testing, and how should be the testing task.
3.6. Recovery Test
- It is the task of testing how well software will recover from crashes, hardware collapses, and other problems. It is the imposed defeat of the software in numerous ways to validate that recovery is correctly happening.
- Name the people who will conduct recovery testing on the project. Make a note of all the persons responsible for this testing.
3.7. Documentation Test
- It is non-functional testing. It is black-box testing that makes sure that documentation, about how to use the software matches what the software does, giving evidence that software modifications and improvements have been documented.
- Name the people who will do documentation testing on the project. Make a note of all the persons responsible for this task.
3.8. Beta Test
- Beta testing is the last round of testing before releasing software to larger customers.
- It is a chance for actual end-users to use the software in a production environment to expose any bugs or defects in a normal release.
3.9. User Acceptance Test
- The user acceptance test aims to check whether the software is ready for operational use or not. During this test, end-users of the software compare the software to its initial conditions.
- Name the people who will conduct user acceptance testing on the project. Make a note of all the persons responsible for this task.
- Define how to conduct user acceptance testing. Name the people who will write the test scripts, what should be the series of events for the user acceptance testing, and how should be the testing task.
4. Environment Requirements
4.1. Data Entry Workstations
It names the minimum hardware essentials that will be used to test the application. The below software is essential as well as client-specific software.
- Windows 8 and above
- Office 2013 and above
- MS Exchange.
4.2 MainFrame
It specifies the essentials and desired effects of the test environment. The particular must consist of the physical attributes of the equipment, and also the hardware, the communications, and system software, the usage model, and other software or collections that are essential to perform the test. Define the level of safety that needs to be given for the test equipment, system software, and exclusive components such as software, data, and hardware. Validate the testing tools that are needed especially. Calculate the source of every need that is not in your group at present.
5. Test Schedule
Every test milestone found in the Software Project Schedule and every unit transmittal event are included here.
- Describe any extra test milestones that are needed.
- Calculate the time needed to finish every testing task.
- Define the schedule for every testing job and test landmark. For every testing facility, describe its duration of use.
6. Control Procedures
-
6.1 Reviews – A review is a step-by-step inspection of a document by one or more persons with the major goal of identifying and solving defects in the initial stages of the software development life cycle. Reviews are used to validate documents like requirements, system designs, code, test plans, and test cases.
-
6.2 Bug Review Meetings – A bug review meeting is an official meeting where all the bugs of the existing module are briefed and met. This meeting normally gathers the major stakeholders who represent the various groups involved in agile software development, engineering, quality assurance, support, product owner, and scrum master.
-
6.3 Change Request – Detail the procedure of changes to the software in a document. Allocate who will work on the modifications and what will be the basis for adding the modifications to the existing software. Suppose, the modifications are affecting the current programs, then these modules must be verified.
- 6.4 Defect Reporting – Detail the process to be followed when an incident happens during the testing procedure in a document. If you are using a standard form, a blank copy should be attached as an “Appendix” to the Test Plan. Write down the process, if you are using an automated incident logging system in the testing. Defect reporting tools must be provided to testers.
7. Functions To Be Tested
Verify every software attribute and combination of the software modules that need to be tested.
8. Resources and Responsibilities
8.1. Resources: The following resources will be used:
- Server: requires a database server that installs MySQL server and a web server that installs Apache server.
- Test tool: Create a testing tool that will auto-generate the test output to the destined form and automated test performance.
- Network: create a network with a LAN gigabit and 1 internet line with a speed of at least 5 Mb/s.
- Computer: At least four computers that will run on Windows 7, RAM 2GB, CPU 3.4GHZ.
8.2. Responsibilities
Make a note of all the staff members who are in this Test Project and what are their roles. Name the groups for managing, designing, preparing, executing, and resolving the test activities and relevant issues. Name the persons for providing the test environment. They may include developers, testers, operations staff, and testing services.
Detail tasks of various members of the team like:
- QA Analyst.
- Test Manager.
- Configuration Manager.
- Developers.
The installation team has to be mentioned here.
The tasks are defined as:
- Test Manager: Supervises the complete project, describes project ways, and attains correct resources.
- Test: Naming and defining appropriate test techniques or tools or automation framework, validating and evaluating the Test Approach, performing the tests, logging results, and reporting the bugs.
- Developer in Test: Performing the test cases, test program, and test suite.
- Test Administrator: Develop and make sure the test environment and assets are supervised and managed and support testers to use the test environment for execution of the test.
- SQA members: They are in charge of quality assurance, they will make sure the testing process is meeting the specified requirements.
9. Deliverables
Recognize the major deliverable documents. Detail all the test deliverables during various stages of the testing. The simple deliverables are the test plan, test cases, requirement traceability matrix, defect reports, the strategy of testing, metrics of testing, and user sign-off. Test deliverables are provided below:
Before Testing Phase
- Test plan document
- Test cases document
- Test design specification
During the Testing Phase
- Simulators of testing tools
- Data required for testing
- Traceability Matrix of testing
- Defects logs and performance logs.
After the Testing Cycle is Completed
- Results or reports of testing
- Bug reporting
- Guidelines for installation or test process
- Release documents
10. Suspension / Exit Criteria
These criteria describe the criteria to be used to hold off on a portion of the testing process.
11. Resumption Criteria
These criteria define when testing can restart after it has been on hold.
12. Dependencies
Here, the requirements of the application are examined before the current software, early stages to test the correct functionality. Recognize notable limitations on testing, such as test item availability, testing resource availability, and deadlines. Also, identify personnel, software, hardware, test data, and database dependencies.
- 12.1 Personnel Dependencies: Requirements depend on individuals in a testing team.
- 12.2 Software Dependencies: Requirements depend on the software or product here.
- 12.3 Hardware Dependencies: Here, requirements depend on hardware components.
- 12.3 Test Data & Database: The testing here depends on the Data to be tested and the database.
13. Risks
We define the chances of risks and chances to avoid those risks. Recognize major-risk calculations in the test plan. Identify possible plans for each one. (Suppose, if there is a delay in the delivery of test items, then it requires work on nights and weekends to meet the delivery date).
13.1. Schedule: The release date for the project gets passed when the risks and tasks are not calculated correctly. This will affect the project and can lead to failure of the project and marks on company finances. Schedule risks occur due to the following reasons:
- The delivery time is calculated improperly.
- Resources tracing is not done correctly. These resources consist of software, staff, and the abilities of the employee.
- The compound tasks are not calculated correctly. Hence time calculation is not made properly.
13.2. Technical: Because of the shortage of performance and execution of functionalities, technical risks occur. Factors causing technical risks are:
- Continuous enhancements in the software requirements.
- Technology development is not available.
- Compound software process.
- Integration of components is tough.
13.3. Management: Causes of management risks:
- Deficiency in resources
- No proper planning of resources
- No communication within the team.
13.4. Personnel: Causes of personnel risks:
- Failure to address priority disputes.
- Failure to solve burdens.
- No correct training in the subject.
13.5 Requirements: Causes of requirement risks:
- Requirements that are not clear
- Requirements that are not complete
- Clashing requirements
- Impractical requirements
- Not enough verification
- Assumptions that are not valid
14. Tools
Identify the testing tools that you are going to use in the project. Name the Bug tracking tools also.
15. Documentation
Requirements, designs, business conditions, configurations, software changes, test plans, test cases, defects reports, and user manuals, may be documented here.
16. Approvals
List the names and titles of all the members who need to accept this plan. Give enough space for the signatures and dates.
Name Signature Date:
1.
2.
A convincing test plan is a very important part of the development project preparation. The test plan document should be clear, short, and modified to changes in the plan or environment. This will make sure each one on your team is striving towards the same aim and that nothing gets missed along the way.