Like any project, when you have a plan in place, chances are it will go smoother.
A test plan in software testing is the document that outlines the what, when, how, who, and more of a testing project. In general, it includes the objective and scope of the tests to be run. A test plan does not include the tests themselves – those are called test cases, and we talk about them in another post.
Test planning is the first thing that should happen in the software testing lifecycle. The test plan document is a living and breathing thing – it is dynamic in the sense that it should always be up to date.
So, Why Create a Test Plan?
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 consider normally. The value alone of writing a test plan is tremendous.
These documents serve as a means of communication across the software team. They can also help track changes to the overall testing project. 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 the new 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 – Create a unique number with 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 subsystems which will be tested.
- Features To Be Tested – The individual features that will be tested within the systems/subsystems 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, percentage 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?
Example Test Plan
Here’s an example test plan following the IEEE 829 format. Feel free to download it and use it as a template for your own projects!