Test Case/Test Script Review Checklist

Item # 1 2 3 Checklist Question Do test cases cover all requirements? Do test cases cover all Testing types described in Test plan? Are the Test Cases/Test Scripts recorded in an automated tool? Are the Test Cases/Test Scripts recorded manually? ! # & ) * 1/ 11 12 13 1 1# 1& 1) 1* 2/ 21 22 23 2 2! 2# Does each Test Case/Test Script possess a unique identi"ier? Are the Test Cases/Test Scripts re"erenced in a $aster Test %lan? Are the Test Cases/Test Scripts traceable bac'(ards to requirements and design? Are the Test Cases/Test Scripts traceable "or(ard to test results? Do the Test Cases speci"y the desired test procedures +steps, actions, activities- "or e.ecuting the tests? Do the Test Cases de"ine the input values required "or test e.ecution? Do the Test Cases de"ine output values +e.pected results- required "or test e.ecution? Does the error message/message code speci"ied in e.pected result "or abnormal cases? Do test cases "or "ield validations, record validations and database updates include the 0alid/1nvalid/2nusual Conditions? Do the test cases "or reports include the test data along (ith the e.pected output? Do the Test Cases record the actual results "or the tests? Do the Test Cases speci"y test data requirements? Do the Test Cases speci"y pre3conditions "or test e.ecution? Do the Test Cases speci"y post3conditions "or test e.ecution? Do the Test Cases provide adequate space "or capturing detailed comments? Do the Test Cases identi"y the system name and system version? Do the Test Cases indicate (hether the test passed or "ailed? Do the Test Cases speci"y inter case dependencies +sequencing- "or the test e.ecution? Do the Test Cases speci"y environmental needs? Do the Test Cases cover security requirements? Do the Test Cases cover privacy requirements? Yes No

Review Findings Summar Instructions

A 4evie( 5indings Summary is a tool created to document and trac' anomalies and issues identi"ied during revie(s6 The 4evie( 5indings Summary contains the "ollo(ing in"ormation7 Item Review T pe #rti"act !e"inition %eer 4evie( or 5ormal 4evie( The category o" the arti"act under revie(, such as7 4equirements Speci"ication Document, So"t(are Design Document, %rototype, Code, Documentation +4elease 8otes, 2ser $anual, Technical $anual, 1nstallation 9uide, Security 9uide-, %atch Description +i" released through 8ational %atch $odule-, Test %lans, and Test %ac'age6 The person (ho created the (or' product under revie(6 The o""icial pro:ect name6 The name o" the so"t(are application to (hich this (or' product pertains6 The version number o" the so"t(are application pertinent to this (or' product6 1" the so"t(are is to be released via the 8ational %atch $odule, enter the patch number6 The date o" the revie( meeting6 The date all anomalies, issues and action items are closed6 A unique identi"ier that permits identi"ication and sorting; suggested %ro:ect acronym < sequential number +i6e6, S24///1The solution "or the identi"ied anomaly6 The date an issue (as resolved and the 4evie( Team agrees it (as resolved correctly6

#uthor $ro%ect #pplication &ersion $atch !ate Review Started !ate Review Closed Identi"ier Resolution !ate Resolved

Item Status

!e"inition T=> 0A41?2S STAT>S T=4?29= @=1C= A8 A8?$AAB %ASS>S ?8 T=> @AB T? 4>S?A2T1?8 A8D CA?S24>6 T=> A8?$AAB STAT>S A4>7 Su'mitted C (hen an item is logged and reported "or repair6 #ssigned C (hen an item is assigned "or repair6 (pened C (hen an anomaly is assigned "or correction6 !eleted C (hen an item is originally reported as an anomaly, but later deleted because the item is either a duplicate or not an anomaly6 Resolved 3 (hen an anomaly is corrected and sent "or revie( or veri"ication6 Re)(pened C (hen an anomaly is closed and then reopened "or modi"ication6 Returned 3 (hen an anomaly is revie(ed, veri"ied as DincorrectD, and returned to author6 &eri"ied 3 (hen an anomaly is revie(ed and veri"ied as DcorrectD6 Closed 3 (hen an anomaly is success"ully revie(ed and closed (ith a resolution and resolution date6 !e"erred 3 (hen an anomaly is designated "or correction at a later date6 !uplicated C (hen an item is assessed to be a duplicate o" a prior record6 *scalated C (hen an item requires evaluation by management6

Note7 The statuses listed above re"lect the use o" 4ational ClearEuest "or anomaly trac'ing6 $anual trac'ing may use a simpli"ied list o" statuses6 Impact The classi"ication o" anomalies according to their potential damage to the so"t(are, systems, patient, personnel or operating systems6 They are classi"ied in three levels7 +igh Impact 3 an error or absence o" "unctionality that may severely :eopardiFe patient or personnel sa"ety; adversely impacts all users; represents a signi"icant value or cost; is governed by Congressional mandate; a""ects either a large database or critical data; requires 5ood and Drug Administration +5DA- certi"ication/approval; a""ects 0eterans 1ntegrated Service 8et(or' +01S8- issues; or negatively impacts the interdependence o" applications6 ,edium Impact 3 an error or absence o" "unctionality that adversely a""ects the sa"ety o" veteran issues or users o" large applications, i6e6, %harmacy, Aab, etc6; represents a high value or cost; sponsored or initiated by the 8ational %rogram ?""ice; or negatively impacts essential operational or business processing6 -ow Impact 3 an error or absence o" "unctionality that may cause operator/user inconvenience and minimally a""ects operational "unctionality