Test coverage defines what you will be testing and what you will not. Test methods define how you will be testing each part defined in the “coverage” section. Test responsibilities assign tasks and responsibilities to different parties. This section should also include what data each party will record and how it will be stored and reported.
29119-1-2013, Software and Systems Engineering - Software Testing - Part 1: Concepts and Definitions[2] X Research source 29119-2-2013, Software and Systems Engineering - Software Testing - Part 2: Test Processes[3] X Research source 29119-3-2013, Software and Systems Engineering - Software Testing - Part 3: Test Documentation[4] X Research source 829-2008, IEEE Standard for Software and System Test Documentation[5] X Research source 1008-1987 - IEEE Standard for Software Unit Testing[6] X Research source
Dublin City University also offers a free test plan template, based on IEEE 829 standards.
Your goals and scope statements should define, in general terms, the methods that will be used in the testing process and the projected results. The scope statement should also include the most critical performance measures, as well as a list of what the test plan will not address, and why. [7] X Research source A schedule details the increments of time in which each phase of the test will be completed. Related documents include any peripheral material that is relevant to the current project, such as lists of specifications.
Determine what the scope of the test is. What scenarios will be tested? Determine what is out of scope for the test. What scenarios will not be tested? Common scenarios include Module Testing, Integration Testing, Systems/Acceptance Testing, and Beta Testing.
When accounting for your staff, make sure to detail the responsibilities required of each member and the training needed to execute those responsibilities. Make sure to document the exact specifications of hardware and software.
Consider the likelihood of various risks. [11] X Research source You will need to prioritize the critical areas. Be aware of any vague or unclear requirements. Users often lack the expertise to understand technical language or procedures, so user misunderstanding could pose a risk. Use your past “bug” history to help you identify areas for concern and extra testing.
You can use software application inventories, IEEE guidelines, and other sources to help you determine this list. This section also represents your “deliverables,” or what data you will deliver to the client once the testing is complete.
The feature will not be included in this version of the software The feature is low-risk or has been used before without issue
Include information on tools to be used, what metrics will be collected and at what level, how many configurations will be tested, and whether there are any special requirements or procedures for testing.
You should also include a list of suspension criteria and resumption requirements. This information tells testers when to pause tests and what the acceptable level of defect is to resume them.
It’s a good idea to assign these deliverables to “owners” who are responsible for their delivery. Assign deadlines by which they are due.
