Test processes determine whether the development products of a given activity conform to the requirements of that activity and whether the system and/or software satisfies its intended use and user needs. The scope of testing encompasses software-based systems, computer software, hardware, and their interfaces.

829-2008 – IEEE Standard for Software and System Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in eight defined stages of software testing, each stage potentially producing its own separate type of document.

Software quality assurance test documentation includes:

Test Plan
A test plan details how the test will proceed, who will do the testing, what will be tested, in how much time the test will take place, and to what quality level the test will be performed.

It’s a document which provides a central artifact to govern the planning and control of the test effort. It defines the general approach that will be employed to test the software and to evaluate the results of that testing, and is the top-level plan that will be used by stakeholders to govern and direct the detailed testing work.

IEEE 829 Test Plan Template

There are  16 clauses of the IEEE 829 test plan standard :
1. Test plan identifier
2. Introduction
3. Test items
4. Features to be tested
5. Features not to be tested
6. Approach
7. Item pass/fail criteria
8. Suspension criteria and resumption requirements
9. Test deliverables
10. Testing tasks
11. Environmental needs
12. Responsibilities
13. Staffing and training needs
14. Schedule
15. Risks and contingencies
16. Approvals

Scope clauses define what features will be tested. 
3. Test Items: The items of software, hardware, and combinations of these that will be tested.
4. Features to Be Tested: The parts of the software specification to be tested.
5. Features Not to Be Tested: The parts of the software specification to be excluded from testing.

Resource clauses give the overall view of the resources to deliver the tasks.
11. Environmental Needs: What’s needed in the way of testing software, hardware, etc.
12. Responsibilities: Who has responsibility for delivering the various parts of the plan.
13. Staffing And Training Needs: The people and skills needed to deliver the plan.

Time clauses specify what tasks are to be undertaken to meet the quality objectives, and when they will occur.
10. Testing Tasks: The tasks themselves, their dependencies, the elapsed time they will take, and the resource required.
14. Schedule: When the tasks will take place.
These two clauses refer to an appendix or another document that contains the detail.

Quality clauses define the standard required from the testing activities.
2. Introduction: A high level view of the testing standard required, including what type of testing it is.
6. Approach: The details of how the testing process will be followed.
7. Item Pass/Fail Criteria: Defines the pass and failure criteria for an item being tested.
9. Test Deliverables: Which test documents and other deliverables will be produced.

Risk clauses define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems.
8. Suspension Criteria And Resumption Requirements: This is a particular risk clause to define under what circumstances testing would stop and restart.
15. Risks And Contingencies: This defines all other risk events, their likelihood, impact and counter measures to over come them.

Plan Clauses are parts of the plan structure.
1. Test Plan Identifier: This is a unique name or code by which the plan can be identified in the project’s documentation including its version.
16. Approvals: The signatures of the various stakeholders in the plan, to show they agree in advance with what it says.



default image

“BAD Testing has been our trusted partner for our most vital clients. We know we can count on a thorough, knowledgeable test team no matter the timeline or the technology. They know how to integrate seamlessly with a team of any size and don’t require any hand-holding and hit the ground running. They are stunningly up-to-date on trends and always able to support the team with the right solution to tough technical problems. Whether it’s a tight timeline or challenging technical work, my first and last call is to BAD Testing.”

Dan Lavorini Vice President, Technical Director - Edelman Digital March 25, 2016

<< Prev
Next >>


© 2012 - 2017 BAD TESTING®, LLC.

Bad Testing, LLC ® is a software QA company that offers computer and technological professional services, namely software quality assurance. BadTesting.com, a software QA website, introduces testing concepts and techniques associated with internet applications.