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.
A list of documents that support the test plan. These might include a project plan, functional specifications, or corporate guidelines.
A summary of the test plan, including the purpose of the the testing project and scope.
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.
The overall strategy of how the tests will be performed.
Completion criteria for the test (minimum number of defects, percentage of passed tests).
Specify what constitutes pausing the test. This might be when a certain number of defects are found.
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.
Any dependencies or remaining activities that must be done.
Any specific tools or hardware that are needed for the tests.
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?
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.
Who signs off on the testing project and approves it to proceed to the next step?
Creating a Test Plan In TestLodge
TestLodge makes it easy to create test plans. With a pre-built template similar to the IEEE 829, you can quickly write and manage your test plans and even track changes to different versions. Try TestLodge for free.
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!