- Mar 21, 2018
- admin
- 0
A test plan helps you and your peers get on the same page. It serves as a framework and a guide to ensure your testing project is successful and helps you control risk. The very act of writing helps us think through things in ways we might not think about normally. The value of writing your plan alone is tremendous.
These documents serve as a means of communication across the software team. They can also help track changes to the testing project overall. As changes to the test plan are made (items to be tested, resources involved, schedule, etc) the test plan document should be updated to reflect those decisions.
There’s no set way of creating a test plan, but there are common suggestions on what to include.
IEEE 829 – A Popular Standard For Test Plan Documentation
Test plans don’t need to be done a certain way, but if you’re new to writing test plans, the IEEE 829 is a good place to start. This standard for test plan documentation is used for software and system testing. It is a good “template” for writing your own test plan documents.
Lets take a look at the different parts of the IEEE 829.
Test Plan Identifier
A unique number in which to identify the plan. This number may include version information and the level of software it’s related to.
References
A list of documents that support the test plan. These might include a project plan, functional specifications, or corporate guidelines.
Introduction
A summary of the test plan, including the purpose of the the testing project and scope.
Test Items
The systems and sub-systems which will be tested.
Features To Be Tested
The individual features that will be tested within the systems/sub-systems during the testing project.
Features Not To Be Tested
A list of features that will not be tested.
Approach
The overall strategy of how the tests will be performed.
Pass/Fail Criteria
Completion criteria for the test (minimum number of defects, % of passed tests).
Suspension Criteria
Specify what constitutes pausing the test. This might be when a certain number of defects are found.
Test Deliverables
The artifacts created by the testing team that are to be delivered upon completion of the test. These could be test cases, output from testing tools, and reports.
Testing Tasks
Any dependencies or remaining activities that must be done.
Environmental Needs
Any specific tools or hardware that are needed for the tests.
Responsibilities
Who’s in charge of the test team and project? This may include training, guiding the strategy, and identifying risks.
Staffing And Training Needs
What resources are needed? Does anyone need additional or special training in order to conduct the test?
Schedule
Details on when the testing will take place.
Risks And Contingencies
The overall risk of the project as it pertains to testing. This might be a lack of resources or a delayed delivering of the software from the development team.
Approvals
Who signs off on the testing project and approves it to proceed to the next step?
Test Planning Activities:
- To determine the scope of testing: (In Scope: Features/functionality to be tested, Out of Scope: Features/functionality NOT to be tested.
- Documenting Test Strategy for current Sprint / Release.
- Making sure that the testing activities have been included.
- Deciding Entry and Exit criteria.
- Evaluating the test estimate.
- Planning when and how to test and deciding how the test results will be evaluated, and defining test exit criterion.
- Determine the risks and assumptions.
- Determine what are the test artifacts delivered as part of test execution.
- Defining the management information, including the metrics required and defect resolution and risk issues.
