118:
responsibilities also include what data will be collected and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties.
95:
Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will
108:
Test methods in the test plan state how test coverage will be implemented. Test methods may be determined by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods also specify test equipment to be used in the performance of the tests and establish
117:
Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test
82:
Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: test coverage, test methods, and test responsibilities. These are also used in a formal
74:
Regression test β to be performed on an existing operational product, to verify that existing functionality was not negatively affected when other aspects of the environment were changed (e.g., upgrading the platform on which an existing application
96:
have one or more corresponding means of verification. Test coverage for different product life stages may overlap but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during
50:
A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from
109:
pass/fail criteria. Test methods used to verify hardware design requirements can range from very simple steps, such as visual inspection, to elaborate test procedures that are documented separately.
133:
standard that specifies the form of a set of documents for use in defined stages of software testing, each stage potentially producing its own separate type of document. These stages are:
65:
Manufacturing test or production test β to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control.
79:
A complex system may have a high-level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components.
58:
Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include a strategy for one or more of the following:
130:
100:, but not repeated during acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access.
341:
62:
Design verification or compliance test β to be performed during the development or approval stages of the product, typically on a small sample of units.
514:
386:
351:
320:
610:
578:
546:
482:
450:
418:
343:
Computational
Science and Its Applications -- ICCSA 2004: International Conference, Assisi, Italy, May 14-17, 2004, Proceedings
310:
630:
654:
97:
68:
Acceptance test or commissioning test β to be performed at the time of delivery or installation of the product.
279:
34:
is a document detailing the objectives, resources, and processes for a specific test session for a
606:
574:
542:
510:
478:
446:
414:
382:
347:
316:
598:
566:
534:
502:
470:
438:
406:
374:
337:
254:
71:
Service and repair test β to be performed as required over the service life of the product.
38:
or hardware product. The plan typically contains a detailed understanding of the eventual
289:
648:
274:
84:
52:
340:; Kumar, Vipin; Mun, Youngsong; Gervasi, Osvaldo; Tan, C. J. Kenneth (2004-05-07).
638:
378:
602:
269:
570:
538:
506:
474:
442:
410:
259:
637:(templates are currently inaccessible but sample documents can be seen here:
186:
The IEEE documents that suggest what should be contained in a test plan are:
17:
264:
284:
126:
39:
35:
563:
1012-1986 - IEEE Standard for
Software Verification and Validation Plans
129:, also known as the 829 Standard for Software Test Documentation, is an
634:
595:
1059-1993 - IEEE Guide for
Software Verification and Validation Plans
371:
829-2008 β IEEE Standard for
Software and System Test Documentation
531:
1012-1998 - IEEE Standard for
Software Verification and Validation
499:
1012-2004 - IEEE Standard for
Software Verification and Validation
233:
IEEE Standard for
Software Verification and Validation Plans
242:
IEEE Guide for
Software Verification & Validation Plans
435:
829-1983 β IEEE Standard for
Software Test Documentation
403:
829-1998 β IEEE Standard for
Software Test Documentation
192:
IEEE Standard for Software and System Test Documentation
226:
IEEE Standard for Software Verification and Validation
220:
IEEE Standard for Software Verification and Validation
309:
Dale, Nell; Weems, Chip; Richards, Tim (2022-07-15).
467:
1008-1987 - IEEE Standard for Software Unit Testing
158:Suspension criteria and resumption requirements
205:IEEE Standard for Software Test Documentation
198:IEEE Standard for Software Test Documentation
8:
365:
363:
346:. Springer Science & Business Media.
312:Programming and Problem Solving with C++
301:
214:IEEE Standard for Software Unit Testing
7:
25:
315:. Jones & Bartlett Learning.
1:
379:10.1109/IEEESTD.2008.4578383
122:IEEE 829 test plan structure
603:10.1109/IEEESTD.1994.121430
173:Staffing and training needs
671:
571:10.1109/IEEESTD.1986.79647
539:10.1109/IEEESTD.1998.87820
507:10.1109/IEEESTD.2005.96278
475:10.1109/IEEESTD.1986.81001
443:10.1109/IEEESTD.1983.81615
411:10.1109/IEEESTD.1998.88820
235:(superseded by 1012-1998)
228:(superseded by 1012-2004)
149:Features not to be tested
207:(superseded by 829-1998)
200:(superseded by 829-2008)
98:design verification test
179:Risks and contingencies
155:Item pass/fail criteria
633:test plan template at
280:Session-based testing
146:Features to be tested
113:Test responsibilities
338:Gavrilova, Marina L.
137:Test plan identifier
167:Environmental needs
516:978-0-7381-4642-3
388:978-0-7381-5747-4
353:978-3-540-22054-1
336:LaganΓ , Antonio;
322:978-1-284-15732-1
161:Test deliverables
16:(Redirected from
662:
655:Software testing
617:
616:
591:
585:
584:
559:
553:
552:
527:
521:
520:
495:
489:
488:
463:
457:
456:
431:
425:
424:
399:
393:
392:
367:
358:
357:
333:
327:
326:
306:
275:Scenario testing
255:Software testing
170:Responsibilities
27:Type of document
21:
670:
669:
665:
664:
663:
661:
660:
659:
645:
644:
626:
621:
620:
613:
593:
592:
588:
581:
561:
560:
556:
549:
529:
528:
524:
517:
497:
496:
492:
485:
465:
464:
460:
453:
433:
432:
428:
421:
401:
400:
396:
389:
369:
368:
361:
354:
335:
334:
330:
323:
308:
307:
303:
298:
251:
124:
115:
106:
93:
48:
28:
23:
22:
15:
12:
11:
5:
668:
666:
658:
657:
647:
646:
643:
642:
629:Public domain
625:
624:External links
622:
619:
618:
611:
586:
579:
554:
547:
522:
515:
490:
483:
458:
451:
426:
419:
394:
387:
359:
352:
328:
321:
300:
299:
297:
294:
293:
292:
290:Ad hoc testing
287:
282:
277:
272:
267:
262:
257:
250:
247:
246:
245:
238:
237:
236:
229:
216:
210:
209:
208:
201:
184:
183:
180:
177:
174:
171:
168:
165:
162:
159:
156:
153:
150:
147:
144:
141:
138:
123:
120:
114:
111:
105:
102:
92:
89:
77:
76:
72:
69:
66:
63:
53:test engineers
47:
44:
26:
24:
14:
13:
10:
9:
6:
4:
3:
2:
667:
656:
653:
652:
650:
640:
636:
632:
628:
627:
623:
614:
612:0-7381-2379-X
608:
604:
600:
596:
590:
587:
582:
580:0-7381-0401-9
576:
572:
568:
564:
558:
555:
550:
548:0-7381-0196-6
544:
540:
536:
532:
526:
523:
518:
512:
508:
504:
500:
494:
491:
486:
484:0-7381-0400-0
480:
476:
472:
468:
462:
459:
454:
452:0-7381-1444-8
448:
444:
440:
436:
430:
427:
422:
420:0-7381-1443-X
416:
412:
408:
404:
398:
395:
390:
384:
380:
376:
372:
366:
364:
360:
355:
349:
345:
344:
339:
332:
329:
324:
318:
314:
313:
305:
302:
295:
291:
288:
286:
283:
281:
278:
276:
273:
271:
268:
266:
263:
261:
258:
256:
253:
252:
248:
243:
239:
234:
230:
227:
223:
222:
221:
217:
215:
211:
206:
202:
199:
195:
194:
193:
189:
188:
187:
181:
178:
175:
172:
169:
166:
164:Testing tasks
163:
160:
157:
154:
151:
148:
145:
142:
139:
136:
135:
134:
132:
128:
127:IEEE 829-2008
121:
119:
112:
110:
103:
101:
99:
91:Test coverage
90:
88:
86:
85:test strategy
80:
73:
70:
67:
64:
61:
60:
59:
56:
54:
45:
43:
41:
37:
33:
19:
18:Test planning
594:
589:
562:
557:
530:
525:
498:
493:
466:
461:
434:
429:
402:
397:
370:
342:
331:
311:
304:
241:
232:
225:
219:
213:
204:
197:
191:
185:
140:Introduction
125:
116:
107:
104:Test methods
94:
81:
78:
57:
49:
31:
29:
639:DBV Samples
635:Sourceforge
270:Test script
244:(withdrawn)
296:References
260:Test suite
240:1059-1993
231:1012-1986
224:1012-1998
218:1012-2004
212:1008-1987
143:Test items
46:Test plans
265:Test case
203:829-1983
196:829-1998
190:829-2008
182:Approvals
32:test plan
649:Category
597:. 1994.
565:. 1986.
533:. 1998.
501:. 2005.
469:. 1986.
437:. 1983.
405:. 1998.
373:. 2008.
285:IEEE 829
249:See also
176:Schedule
152:Approach
40:workflow
36:software
609:
577:
545:
513:
481:
449:
417:
385:
350:
319:
75:runs).
607:ISBN
575:ISBN
543:ISBN
511:ISBN
479:ISBN
447:ISBN
415:ISBN
383:ISBN
348:ISBN
317:ISBN
131:IEEE
631:RUP
599:doi
567:doi
535:doi
503:doi
471:doi
439:doi
407:doi
375:doi
651::
605:.
573:.
541:.
509:.
477:.
445:.
413:.
381:.
362:^
87:.
55:.
42:.
30:A
641:)
615:.
601::
583:.
569::
551:.
537::
519:.
505::
487:.
473::
455:.
441::
423:.
409::
391:.
377::
356:.
325:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.