Test planning, the most essential action to guarantee that there is at first a list of task and breakthroughs in a base line plan to track the advance of the project. It additionally characterizes size of test effort.It is the primary document called as master test design or a project test plan and generally developed during the early period of the project.
Why Create a Test Plan?
A test plan causes you and your associates get in same page. It fills in as a structure and a manual for guarantee your testing project is effective and helps you control risk. The very act writing of composing causes us thoroughly consider things in ways we won’t not consider normally. The value of writing your plan alone is tremendous.
These documents fill in as methods for communication over the software team. They can likewise help track changes to the testing project by and large. As changes to the test plan are made (items to be tested, resources involved, schedule, etc) the test design record ought to be refreshed to mirror those decisions.
One can have the following types of test plans:
- Master Test Plan: A solitary high level test plan a project/product that brings together all other test plans.
- Testing Level Specific Test Plans: Plans for each level of testing.
- System Test Plan
- Integration Test Plan
- Acceptance Test Plan
- Unit Test Plan
- Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security Test Plan.
Test Plan Identifier:
- Provide a unique identifier for the document. (Adhere to the Configuration Management System if you have one.)
Introduction for Test Plan:
- Provide an overview of the test plan.
- Specify the goals/objectives.
- Specify any constraints.
References of Test Plan:
- List the related documents, with links to them if available, including the following
- Project Plan
- Configuration Management Plan
Test Items will be needed:
- List the test items (software/products) and their versions.
Features which are to be Tested:
- List the features of the software/product to be tested.
- Provide references to the Requirements and/or Design specifications of the features to be tested
Features which are Not to Be Tested:
- List the features of the software/product which will not be tested.
- Specify the reasons these features won’t be tested.
Approach for Test Plan:
- Mention the overall approach to testing.
- Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]
Item Pass/Fail Criteria:
- Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.
Suspension Criteria and Resumption Requirements:
- Specify criteria to be used to suspend the testing activity.
- Specify testing activities which must be redone when testing is resumed.
- List test deliverable, and links to them if available, including the following:
- Test Plan (this document itself)
- Test Cases
- Test Scripts
- Defect/Enhancement Logs
- Test Reports
Test Environment for Test Plan:
- Specify the properties of test environment: hardware, software, network etc.
- List any testing or related tools.
Estimate for Test Plan:
- Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.
Schedule for Test Plan:
- Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.
Staffing and Training Needs:
- Specify staffing needs by role and required skills.
- Identify training that is necessary to provide those skills, if not already acquired.
Responsibilities to create Test Plan :
- List the responsibilities of each team/role/individual.
- List the risks that have been identified.
- Specify the mitigation plan and the contingency plan for each risk.
- Specify the names and roles of all persons who must approve the plan.
- Provide space for signatures and dates. (If the document is to be printed.)
Here are a few important pointers regarding a test plan
- Test Plan is a report that is the perspective in view of which testing is done inside the QA team.
- It is additionally a document we share with the Business Analysts, Project Managers, Dev team and alternate teams. This is to upgrade the level of straightforwardness into the QA team’s attempting to the outer teams.
- It is recorded by the QA manager/QA toxic on the contributions from the QA team members.
- Test Planning is normally dispensed 1/3 of the time it takes for the whole QA engagement. The other 1/third is for Test Designing and rest is for Test Execution.
- Test arrangement is not static and is refreshed on an on request premise.
- The more details and exhaustive the Test design, the more fruitful the testing action.