Produced by Araxis Merge on 12/7/2017 6:26:48 PM Eastern Standard Time. See www.araxis.com for information about Merge. This report uses XHTML and CSS2, and is best viewed with a modern standards-compliant browser. For optimum results when printing this report, use landscape orientation and enable printing of background images and colours in your browser.
# | Location | File | Last Modified |
---|---|---|---|
1 | OSCIF_CPEE_Sprint_1 and 2.zip\Build 4 Deliverables | CPE Project Build 4 Test Plan_v0.1_09192017.docx | Thu Dec 7 15:13:22 2017 UTC |
2 | OSCIF_CPEE_Sprint_1 and 2.zip\Build 4 Deliverables | CPE Project Build 4 Test Plan_v0.1_09192017.docx | Thu Dec 7 18:49:12 2017 UTC |
Description | Between Files 1 and 2 |
|
---|---|---|
Text Blocks | Lines | |
Unchanged | 1 | 852 |
Changed | 0 | 0 |
Inserted | 0 | 0 |
Removed | 0 | 0 |
Whitespace | |
---|---|
Character case | Differences in character case are significant |
Line endings | Differences in line endings (CR and LF characters) are ignored |
CR/LF characters | Not shown in the comparison detail |
No regular expressions were active.
1 | Community Care Syste ms Enhance ments (CCS E) | |
2 | Claims Pro cessing an d Eligibil ity (CP&E) Enhanceme nts Build 4 | |
3 | Master Tes t Plan | |
4 | Version 0. 1 | |
5 | ||
6 | ||
7 | ||
8 | ||
9 | Department of Vetera ns Affairs | |
10 | Office of Informatio n and Tech nology (OI &T) | |
11 | ||
12 | ||
13 | September 2017 | |
14 | ||
15 | ||
16 | Document V ersion and Review Hi story | |
17 | Date | |
18 | Version | |
19 | Descriptio n | |
20 | Author | |
21 | Reviewed B y | |
22 | 09/19/2017 | |
23 | 0.1 | |
24 | Initial te mplate upd ated for B uild 4 | |
25 | Faith Donn elly | |
26 | Mike Synak iewcz | |
27 | Note: The revision h istory cyc le begins once chang es or enha ncements a re request ed after t he Build T est Plan h as been ba selined. | |
28 | ||
29 | ||
30 | Table of C ontents | |
31 | ||
32 | 1.Introduc tion4 | |
33 | 1.1.Purpos e4 | |
34 | 1.2.Test O bjectives4 | |
35 | 1.3.Key Ro les and Re sponsibili ties5 | |
36 | 1.4.Proces ses and Re ferences5 | |
37 | 2.Items to Be Tested 6 | |
38 | 2.1.Overvi ew of Test Inclusion s6 | |
39 | 2.2.Overvi ew of Test Exclusion s6 | |
40 | 3.Test Str ategy6 | |
41 | 3.1.Testin g Types7 | |
42 | 3.2.Produc tivity and Support T ools7 | |
43 | 4.Test Cri teria8 | |
44 | 4.1.Proces s Reviews8 | |
45 | 4.2.Pass/F ail Criter ia8 | |
46 | 4.3.Suspen sion and R esumption Criteria8 | |
47 | 4.4.Defini tion of Do ne9 | |
48 | 4.5.Accept ance Crite ria9 | |
49 | 5.Test Del iverables1 0 | |
50 | 6.Sprint S chedule10 | |
51 | 7.Test Env ironments1 1 | |
52 | 7.1.System Hardware1 1 | |
53 | 7.2.System Software in the Tes t Environm ents11 | |
54 | 8.Dependen cies11 | |
55 | 9.Risks an d Constrai nts12 | |
56 | 10.Test Me trics13 | |
57 | 11.Glossar y13 | |
58 | Appendix A - Testing Definitio ns15 | |
59 | ||
60 | ||
61 | ||
62 | Introducti on | |
63 | The Claims Processin g and Elig ibility (C P&E) proje ct address es improve d function ality to i nclude the following : initial claims pro cessing, v endor sele ction and travel cla ims point of pickup suspense q ueues, cla im review and cleari ng, modifi cations to document identifica tion softw are automa tic system imaging a nd storing of templa te letters requestin g addition al informa tion. The overall ob jective fo r this pro ject cente rs on incr eased prod uctivity, reduction of imprope r payments , and impr oved custo mer servic e. The CP& E Project includes W orkstreams for Elect ronic Data Interchan ge (EDI) C laims Reop en and Ven dor Stream lining. | |
64 | The EDI Cl aims Reope n process will allow the Healt h Claims R eimburseme nt group t o reopen E DI claims in the Cac he system and then p rocess tho se reopene d claims. The Office of Commun ity Care ( OCC) has r equested a modificat ion to sys tem functi onality an d business processes active in the CP&E system. Th is modific ation will allow for a Voucher Examiner (VE) to re open claim s and allo w the VE t o re-adjud icate clai ms for whi ch the ser vice provi der has re quested re considerat ion, witho ut requiri ng a print and scan of the cla im as a wo rk around. | |
65 | The Vendor Streamlin ing proces s carried out in the Image Pro cessing (I P) menu op tion by VE is import ant for se veral reas ons: | |
66 | Ensure tha t provider s who care for benef iciaries a re paid fo r their se rvices in a timely m anner | |
67 | Ensure the payment g oes to the correct v endor | |
68 | Verify pay -to-provid er and ini tiate any correction s to the v endor | |
69 | Have new v endors or locations added to t he system (and there by, be ver ified by t he Vendor Queue team ) | |
70 | Reduce fra udulent an d errant r emit-to (R T) claims | |
71 | Improve th e overall claims pro cessing sp eed and ac curacy | |
72 | The object ive of the vendor se lection pr ocess is t o search t he Vendor Look-Up Fi le in CP&E to locate the vendo r record t hat matche s the RT i nformation on the bi ll. This p rocess ens ures accur ate Civili an Health and Medica l Program of the Dep artment of Veterans Affairs (C HAMPVA) pa yment and delivery t o the prop er billing address. | |
73 | Purpose | |
74 | The purpos e of the B uild Test Plan for t he CP&E Pr oject deli verables i s to descr ibe the ov erall appr oach, i.e. , to defin e the test levels an d types of tests pla nned throu ghout the life cycle , includin g testing activities , resource s to perfo rm those a ctivities, schedule of test ac tivities, assigned r esponsibil ities, pro vide defin ition of “ done”, and identify resources required t o determin e readines s of the B uild. | |
75 | Test Objec tives | |
76 | This Build Test Plan supports the follow ing object ives: | |
77 | Identify s cope for t he Build ( test activ ities) | |
78 | Identify t he test en vironment( s) for the Build | |
79 | Validate s tatus and stability of test en vironment | |
80 | Support Us er Functio nal Testin g (UFT/UAT ) with Sub ject Matte r Experts (SMEs) | |
81 | Provide de fect repor ting and r esolution process fo r the Buil d | |
82 | Key Roles and Respon sibilities | |
83 | The follow ing table lists the key roles that suppo rt the exe cution of the Build Test Plan. | |
84 | Table 1: K ey Roles a nd Descrip tions | |
85 | Role | |
86 | Descriptio n | |
87 | Developmen t Lead | |
88 | Person who creates o r updates the Busine ss Policy or Busines s Rules | |
89 | Product Le ad | |
90 | Person who is overal l responsi ble for th e successf ul plannin g and exec ution of a project; responsibl e for crea ting the B uild Test Plan in co llaboratio n with the Developme nt Lead. | |
91 | Stakeholde rs | |
92 | Persons wh o hold a s take in a situation in which t hey may af fect or be affected by the out come. | |
93 | Test Team/ Testers | |
94 | Persons wh o execute and ensure s the test environme nt will ad equately s upport pla nned activ ities. Per sons respo nsible for ensuring full execu tion of th e test pro cess to in clude the verificati on of tech nical requ irements a nd the val idation of business requiremen ts. Leads and coordi nates acti vities rel ated to as pects of t esting bas ed on an a pproved Bu ild Test P lan and sc hedule | |
95 | Configurat ion Manage ment | |
96 | Person who establish es, mainta ins, and c ontrols te st environ ments. | |
97 | Business A nalyst | |
98 | Person who analyzes the busine ss process and its i ntegration with tech nology. Ac ts as a li aison amon g stakehol ders to un derstand t he structu re, polici es, and op erations o f an organ ization, a nd recomme nd solutio ns that en able the o rganizatio n to achie ve its goa ls. | |
99 | Processes and Refere nces | |
100 | The proces ses that g uide the i mplementat ion of thi s Build Te st Plan ar e: | |
101 | Test Prepa ration | |
102 | Product Bu ild | |
103 | Independen t Test and Evaluatio n | |
104 | The refere nces that support th e implemen tation of this Build Test Plan are: | |
105 | Veteran Fo cused Inte gration Pr ocess (VIP ) | |
106 | Performanc e Work Sta tement (PW S) | |
107 | Build Plan | |
108 | Sprint Pla n | |
109 | Business R equirement s Document (BSM_CPEE _BRD_V02.0 0.00_Draft _Oct 2016) | |
110 | Items to B e Tested | |
111 | Overview o f Test Inc lusions | |
112 | CP&E Proje ct testing is develo ped based on the pro duct backl og from th e Business Requireme nts Docume nt (BRD), direction from the c ustomer, a s well as change req uests subm itted by t he Central Business Office Com munity Car e (CBOCC) users over the cours e of month s and year s are revi ewed and p rioritized as part o f the ongo ing operat ions and m aintenance of the ba cklog for the CP&E s ystem. | |
113 | ||
114 | CP&E EPIC 005 EDI Cl aims Reope n (CR ENC0 05415): | |
115 | “As the He alth Claim s Reimburs ement grou p, I want to reopen EDI claims in the Ca che system so I can process re opened EDI claims in the Cache system.” | |
116 | Overview o f Test Exc lusions | |
117 | The follow ing compon ents and f eatures, a nd combina tions of c omponents and featur es, will n ot be test ed: | |
118 | No known e xclusions at this ti me. Items are identi fied durin g testing and will b e captured according ly. | |
119 | Test Strat egy | |
120 | This secti on details tests tha t the CP&E Project d evelopment team and stakeholde rs plan to cover for this Buil d. The tes t approach includes the follow ing steps: | |
121 | Develop te st cases b ased on th e User Sto ries creat ed | |
122 | Collaborat e with VA Business S MEs | |
123 | Perform al l testing, in the CP &E DEV Env ironment | |
124 | Perform Te st Readine ss Review (TRR) | |
125 | Execute te st cases a nd documen t test res ults | |
126 | Log and re port test defects fo r tracking and resol ution | |
127 | Based on t he approve d User Sto ries plann ed for com pletion in Section 2 .1, code d elivery is anticipat ed on . | |
128 | Upon deliv ery of the code to t he Denver OCC Qualit y Assuranc e (QA) Dep artment, t esting per formed by the QA tea m will hav e support from FTC. UFT/UAT te sting will be perfor med after QA is comp lete. Both QA and UF T/UAT anti cipate the need for approximat ely 30 to 45 busines s days eac h to final ize testin g efforts. | |
129 | UNION Appr oval | |
130 | Notify Uni on Represe ntative(s) of any ch anges in w orking con ditions | |
131 | The Union Representa tive(s) to respond w ithin 14 d ays | |
132 | Dependency is IT QA completion which wil l generate the SOP n eeded to b egin UAT a nd union n otificatio n | |
133 | Union Repr esentative (s) will s end propos ed changes to Union members an d ask for feedback a nd/or acce ptance | |
134 | FTC will r espond to any union issues or concerns d uring the 14 days | |
135 | Training P lan, if ne eded, will be provid ed to Unio n represen tative in conjunctio n with the union not ification, near the end of UAT | |
136 | Obtain Uni on accepta nce | |
137 | FTC expect s improvem ents to cu rrent prod uctivity a nd does no t anticipa te any neg ative impa cts to pro ductivity with minim al trainin g | |
138 | Testing Ty pes | |
139 | This secti on describ es the pot ential typ es of test activitie s to be pe rformed in this proj ect. | |
140 | Table 2: T est Types | |
141 | Test Types | |
142 | Party Resp onsible | |
143 | Unit/Produ ct/Compone nt Testing | |
144 | Developers /FTC SQA | |
145 | Functional Testing | |
146 | FTC SQA | |
147 | Installati on Testing | |
148 | OIT/OCC | |
149 | Integratio n/System T esting | |
150 | Developers /FTC SQA | |
151 | Backend Te sting | |
152 | Developers /FTC SQA | |
153 | Regression and Negat ive Testin g | |
154 | FTC SQA | |
155 | Section 50 8 Complian ce Testing | |
156 | FTC SQA | |
157 | OCC QA and User Func tional Tes ting (UFT/ UAT) | |
158 | OIT/OCC | |
159 | ||
160 | Productivi ty and Sup port Tools | |
161 | This secti on describ es the too ls that wi ll be empl oyed to su pport this Build Tes t Plan. | |
162 | Table 3: T ool Catego ry or Type s | |
163 | Tool Categ ory or Typ e | |
164 | Tool Brand Name | |
165 | Defect Tra cking | |
166 | Rational Q uality Man ager (RQM) | |
167 | Project Ma nagement | |
168 | Rational D OORS Next Generation Requireme nts Manage ment (RDNG ) | |
169 | Unit Testi ng | |
170 | J-Unit/M-U nit, RQM | |
171 | Configurat ion Manage ment | |
172 | Rational T eam Concer t (RTC) Co nfiguratio n and Chan ge Managem ent | |
173 | DBMS tools | |
174 | Fileman | |
175 | Functional Testing | |
176 | RQM, Visua l Basic fo r Applicat ions (VBA) , Notepad | |
177 | Terminal E mulation S oftware | |
178 | Attachmate Reflectio n | |
179 | Continuous Integrati on (CI) | |
180 | Jenkins | |
181 | 508 Compli ance | |
182 | JAWS | |
183 | Test Crite ria | |
184 | Process Re views | |
185 | The CP&E P roject Bui ld Test Pl an undergo es the fol lowing rev iews: | |
186 | Peer Revie w – Projec t Team pee r review u pon comple tion of th e draft Bu ild Test P lan | |
187 | Formal Rev iew – The Test Leads , Product Lead and V A Stakehol ders colle ctively re view and a pprove the Build Tes t Plan | |
188 | Pass/Fail Criteria | |
189 | An item or test case will be c onsidered to pass if it meets the busine ss require ments, as defined in the User Stories, i n an accep table mann er and/or has an acc eptable wo rk-around, which has been appr oved by al l project stakeholde rs. An ite m or test case will fail if it does not meet the b usiness re quirements , as defin ed in the User Stori es, in an acceptable manner an d/or does not have a n acceptab le work-ar ound appro ved by all project s takeholder s. | |
190 | Suspension and Resum ption Crit eria | |
191 | The suspen sion of te sting occu rs when te sters enco unter a cr itical or high defec t. The err or may app ly to a pa rticular a rea of the product a nd often c auses all testing to be suspen ded. When a critical or high d efect occu rs, the FT C Technica l Leads an d the Offi ce of Info rmation & Technology (OIT) Pro gram Manag ement Offi ce (PMO) T echnical L eads will discuss th e impact o f the defe ct and det ermine whe ther to su spend test ing and, i f so, whic h product areas are affected. The test s uspension causes tes ting to be suspended or blocke d until th e FTC deve lopers and testers c an install and unit test a fix or work-a round. | |
192 | Suspension condition s include: | |
193 | A blocking defect is discovere d during t est execut ion such t hat no fur ther progr ess is pos sible unti l the defe ct is reso lved | |
194 | The test e nvironment is corrup ted or ren dered unus able | |
195 | Project ma nagement d etermines the need t o suspend testing ba sed on som e other cr iteria | |
196 | Resumption criteria are: | |
197 | The condit ion that c aused the suspension is addres sed | |
198 | The change s are unit /component tested | |
199 | The change s are appl ied to the test envi ronment | |
200 | The initia l entry cr iteria of the test p hase are m et | |
201 | Definition of Done | |
202 | All requir ed testing deliverab les will b e complete d, approve d by the c ustomer an d posted t o Rational . | |
203 | ||
204 | The follow ing criter ia will be met for e ach User S tory inclu ded in thi s Build: | |
205 | Unit and S QA testing completio n | |
206 | Acceptance criteria achievemen t for each User Stor y tested | |
207 | All testin g phases c ompleted, passed and accepted by the cus tomer | |
208 | All known defects re solved or documented for resol ution in a future Bu ild | |
209 | Acceptance Criteria | |
210 | Testing co mpleted fo r the CP&E Project m ust meet t he criteri a listed b elow, to b e accepted . These it ems repres ent combin ed accepta nce criter ia for FTC testing e fforts and existing quality ob jectives i dentified in Rationa l QM. | |
211 | The testab le, functi onal requi rements fo r the Buil d must be tested and verified | |
212 | All defect s with a l evel of cr itical, hi gh and med ium are re solved, re tested and closed | |
213 | Number of Open Sev1 and Sev2 D efects = 0 | |
214 | All defect s with a l evel of lo w are reso lved or pl aced in ba cklog for future Bui ld | |
215 | Percentage of Sev3 o r lower De fects Open < 10 | |
216 | All the te st cases a re execute d without defects at a medium or higher level | |
217 | Number of Blocked Ex ecution Re cords = 0, Percentag e of Block ed Executi on Records = 0% | |
218 | Number of Failed Exe cution Rec ords = 0, Percentage of Failed Execution Records = 0% | |
219 | Any outsta nding test cases fro m a previo us test ru n have suc cessfully passed | |
220 | The follow ing list r epresents severity l evels, as defined in Rational: | |
221 | Severity 1 | |
222 | Critical I mpact/Syst em Down | |
223 | Severity 2 | |
224 | Significan t business impact | |
225 | Severity 3 | |
226 | Some busin ess impact | |
227 | Severity 4 | |
228 | Minimal bu siness imp act | |
229 | Test Deliv erables | |
230 | Table 4 li sts the te st deliver ables for the CP&E P roject. | |
231 | Table 4: T est Delive rables | |
232 | Test Deliv erables | |
233 | Frequency | |
234 | Build Test Plan | |
235 | Per Build | |
236 | Test Resul ts and Exe cution Rep ort | |
237 | Per Sprint /Daily in Rational | |
238 | Test Cases /Test Scri pts | |
239 | Per Build in Rationa l | |
240 | Defect Sta tus and Re solution | |
241 | Daily/As N eeded | |
242 | Section 50 8 Complian ce Test Re sults | |
243 | Per Build | |
244 | Traceabili ty Report or Matrix | |
245 | Per Build/ As Needed | |
246 | Sprint Sch edule | |
247 | This secti on lists t he schedul e for CP&E Project. Note: This is an Agi le develop ment proje ct and goe s by each Sprint. | |
248 | Table 5: S print Sche dule | |
249 | Sprint # | |
250 | Start Date | |
251 | Finish Dat e | |
252 | Sprint 1 | |
253 | 9/28/17 | |
254 | 10/10/17 | |
255 | Sprint 2 | |
256 | 10/11/017 | |
257 | 10/24/17 | |
258 | Sprint 3 | |
259 | 10/25/17 | |
260 | 11/7/17 | |
261 | Sprint 4 | |
262 | 11/8/17 | |
263 | 11/21/17 | |
264 | Sprint 5 | |
265 | 11/22/17 | |
266 | 12/5/17 | |
267 | Test Envir onments | |
268 | A test env ironment c ontains ha rdware, in strumentat ion, simul ators, sof tware tool s, and oth er support elements needed to conduct a test. All planned de velopment and testin g will occ ur in the DEV enviro nment at t he Office of Communi ty Care (O CC). The D enver OCC will be re sponsible for config uring and maintainin g the test environme nts. | |
269 | The OCC pr oducts/sys tems plann ed to be m odified in this Buil d are: | |
270 | CP&E | |
271 | System Ha rdware | |
272 | N/A | |
273 | System Sof tware in t he Test En vironments | |
274 | Table 7 de scribes th e base sof tware elem ents that are requir ed in the test envir onment for this Buil d Test Pla n. | |
275 | Table 6: S oftware El ements | |
276 | Software E lement Nam e | |
277 | Version | |
278 | Type and O ther Notes | |
279 | CP&E DEV n amespace | |
280 | ||
281 | ||
282 | Dependenci es | |
283 | The follow ing depend encies and constrain ts must be considere d to succe ssfully ex ecute this Build: | |
284 | The Enterp rise Progr am Managem ent Office (EPMO) IT developme nt resourc es are req uired to a nswer spec ific techn ical quest ions | |
285 | OCC busine ss resourc es are req uired to a nswer spec ific busin ess proces s and proc edure ques tions | |
286 | Coordinati on of code deploymen t with the Denver OC C | |
287 | HAC resour ce will be required to answer specific t echnical q uestions r egarding d evelopment , testing and implem entation i ssues. | |
288 | QA and UFT /UAT testi ng is depe ndent upon HAC QA re source ava ilability and requir ed prior t o deployme nt into pr oduction | |
289 | ||
290 | Risks and Constraint s | |
291 | The test p reparation process r equires th e performa nce of a r isk assess ment for t est execut ion. Risks associate d with the testing p roject are potential problems/ events tha t may caus e damage t o the soft ware, syst ems, patie nt, person nel, opera ting syste ms, schedu le, scope, budget or resources . The risk s outlined here may impact sco pe and sch edule, nec essitating a deviati on from th is Build T est Plan. | |
292 | ||
293 | Risk Descr iption | |
294 | Potential Impact of Risk Reali zation | |
295 | Strategy - avoid, ac cept or mi tigate | |
296 | Integrated environme nt and/or component, including the assoc iated netw ork connec tivity, ar e unavaila ble | |
297 | Impacts th e SQA Team ’s ability to comple te their s cheduled t esting wit hin the ti meframe al located. | |
298 | Mitigate: | |
299 | Adjust tes t/work sch edules; wo rk with ex ternal gro ups to avo id outages | |
300 | If the ext ernal syst ems experi ence an ou tage, or p erform any un-planne d refreshe s | |
301 | Impacts th e SQA sche dule | |
302 | Mitigate: | |
303 | Work close ly with ex ternal sys tems to en sure these refreshes or outage s are coor dinated wi thin the s chedule | |
304 | Requiremen ts deliver y late | |
305 | Risk to th e schedule due to la te start b y developm ent | |
306 | Mitigate: | |
307 | Adjust tes t schedule ; compress testing a ctivities; request s chedule va riance | |
308 | Stakeholde r non-comp liance (de lays in si gn-off) | |
309 | Risk to th e final de livery dat e due to d elays in F ield Test completion or approv al to rele ase | |
310 | Mitigate: | |
311 | Maintain c lose conta ct with al l stakehol ders, keep ing them a pprised of deadlines | |
312 | Working wi th Integra ted teams | |
313 | New system version c an impact testing an d schedule | |
314 | Mitigate: | |
315 | Coordinate ; communic ate with i ntegrated teams and plan ahead so that s chedule wi ll be impa cted at a minimum | |
316 | Potential issues dur ing deploy ment of Bu ild | |
317 | Risk to th e schedule , potentia l delay in Builds av ailable fo r testing | |
318 | Mitigate o r Accept | |
319 | Accept del ay | |
320 | Adjust tes t schedule ; compress testing a ctivities; request s chedule va riance | |
321 | ||
322 | In additio n, to help ing ensure the succe ss of the Build, it is importa nt to proa ctively mo nitor inte rnal and e xternal ev ents that affect a p roduct obj ective wit h respect to cost, s chedule, o r technolo gy. | |
323 | This secti on lists i dentified risks that will like ly impact Build 4. D uring this Build, ri sks and is sues will be tracked on the PM O Risk Reg ister unti l Rational is fully set up and configure d for use. | |
324 | Build acti vities may be negati vely impac ted due to a HAC sys tem refres h, current ly planned for Septe mber 11th through No vember 22n d, 2017. P lanning fo r future B uilds may also be ef fected dur ing this t ime. | |
325 | Unplanned leaves of absence wi ll be miti gated by b oth the pr oject and developmen t teams. ( Teams shou ld have va cation sch edules.) | |
326 | Project ri sks will b e reported and track ed on the Risk Regis ter in the Weekly Ri sk meeting facilitat ed by the OI&T PM un til Ration al is conf igured to manage ris ks. This f ile is on the CP&E S harePoint site. | |
327 | If availab ility of t est data a nd test fi les is res tricted, t hen it wil l reduce t he capabil ity of com plete test cases. | |
328 | The risks identified in this B uild Test Plan may b e recorded and track ed in the Business S ystems Man agement (B SM) tool i n SharePoi nt. | |
329 | Test Metri cs | |
330 | Metrics ar e a system of parame ters or me thods for quantitati ve and per iodic asse ssment of a process that is to be measur ed. | |
331 | Test metri cs may inc lude, but are not li mited to: | |
332 | Number of test cases (pass/fai l) | |
333 | Percentage of test c ases execu ted | |
334 | Number of requiremen ts and per centage te sted | |
335 | Percentage of test c ases resul ting in de fect detec tion | |
336 | Number of defects at tributed t o test cas e/test scr ipt creati on | |
337 | Percentage of defect s identifi ed; listed by cause and severi ty | |
338 | Glossary | |
339 | Acronym | |
340 | Definition | |
341 | BRD | |
342 | Business R equirement s Document | |
343 | BSM | |
344 | Business S ystems Man agement | |
345 | CCSE | |
346 | Community Care Syste m Enhancem ents | |
347 | CP&E | |
348 | Claims Pro cessing an d Eligibil ity | |
349 | CBOCC | |
350 | Central Bu siness Off ice Commun ity Care | |
351 | CHAMPVA | |
352 | Civilian H ealth and Medical Pr ogram of t he Departm ent of Vet erans Affa irs | |
353 | CDR | |
354 | Clinical D ata Reposi tory | |
355 | DEV | |
356 | Developmen t | |
357 | EDI | |
358 | Electronic Data Inte rchange | |
359 | EPMO | |
360 | Enterprise Program M anagement Office | |
361 | ERA | |
362 | Electronic Remittanc e Advice | |
363 | HAC | |
364 | Health Adm inistratio n Center | |
365 | IP | |
366 | Image Proc essing | |
367 | OIT | |
368 | Office of Informatio n Technolo gy | |
369 | OCC | |
370 | Office of Community Care | |
371 | PMO | |
372 | Program Ma nagement O ffice | |
373 | PWS | |
374 | Performanc e Work Sta tement | |
375 | RT | |
376 | Remit-To | |
377 | SME | |
378 | Subject Ma tter Exper t | |
379 | SQA | |
380 | Software Q uality Ass urance | |
381 | TRR | |
382 | Test Readi ness Revie w | |
383 | UFT/UAT | |
384 | User Funct ional Test ing / User Acceptanc e Test | |
385 | US | |
386 | Ultrasound | |
387 | VBA | |
388 | Visual Bas ic for App lications | |
389 | VA | |
390 | Department of Vetera ns Affairs | |
391 | VE | |
392 | Voucher Ex aminer | |
393 | VistA | |
394 | Veterans H ealth Info rmation Sy stems and Technology Architect ure | |
395 | ||
396 | ||
397 | Appendix A - Testing Definitio ns | |
398 | ||
399 | Test Type | |
400 | Definition | |
401 | Backend Te sting | |
402 | Example: D ata and Da tabase Int egrity Tes ting is a type of te sting that verifies that data is being s tored by t he system in a manne r where th e data is not compro mised by t he initial storage, updating, restoratio n, or retr ieval proc essing. Th is type of testing i s intended to uncove r design f laws that may result in data c orruption, unauthori zed data a ccess, lac k of data integrity across mul tiple tabl es, and la ck of adeq uate trans action per formance. The databa ses, data files, and the datab ase or dat a file pro cesses sho uld be tes ted as a s ubsystem w ithin the applicatio n. | |
403 | Functional Testing | |
404 | A type of black-box testing th at bases i ts test ca ses on the specifica tions of t he softwar e componen t under te st. Functi ons are te sted by fe eding them input and examining the outpu t, and int ernal prog ram struct ure is rar ely consid ered (unli ke white-b ox testing ). Functio nal testin g usually describes what the s ystem does . Function al testing has many types, inc luding, bu t not limi ted to: un it, integr ation, smo ke, regres sion, usab ility, sys tem, etc. | |
405 | Installati on Testing | |
406 | A type of testing th at verifie s that the applicati on or syst em install s as inten ded on dif ferent har dware and software c onfigurati ons, and u nder diffe rent condi tions (e.g ., a new i nstallatio n, an upgr ade, and a complete or custom installati on). Insta llation te sting may also measu re the eas e with whi ch an appl ication or system ca n be succe ssfully in stalled, t ypically m easured in terms of the averag e amount o f person-h ours requi red for a trained op erator or hardware e ngineer to perform t he install ation. Par t of this installati on test is to perfor m an unins tall. Beca use of thi s uninstal l, the sys tem, appli cation and database should ret urn to the state pri or to the install. | |
407 | Integratio n Testing | |
408 | An increme ntal serie s of tests of combin ations or subassembl ies of sel ected comp onents in an overall system. I ntegration testing i s incremen tal in a s uccessivel y larger a nd more co mplex comb inations o f componen ts tested in sequenc e, proceed ing from t he unit le vel (0% in tegration) to eventu ally the f ull system test (100 % integrat ion). | |
409 | Load Testi ng | |
410 | A performa nce test t hat subjec ts the sys tem to var ying workl oads to me asure and evaluate t he perform ance behav iors and a bilities o f the syst em to cont inue to fu nction pro perly unde r these di fferent wo rkloads. L oad testin g determin es and ens ures that the system functions properly beyond the expected maximum wo rkload. Ad ditionally , load tes ting evalu ates the p erformance character istics (e. g., respon se times, transactio n rates, a nd other t ime-sensit ive issues ). | |
411 | Performanc e Testing | |
412 | Performanc e Testing assesses h ow a syste m is spend ing its ti me and con suming res ources. Pe rformance testing op timizes a system by measuring how much t ime and re sources th e system i s spending in each f unction. T hese tests identify performanc e limitati ons in the code and specify wh ich sectio ns of the code would benefit m ost from o ptimizatio n work. Pe rformance testing ma y be furth er refined using spe cific type s of perfo rmance tes ts, such a s, benchma rk test, l oad test, stress tes t, perform ance monit oring test , and cont ention tes t. | |
413 | Regression Testing | |
414 | A type of testing th at validat es existin g function ality stil l performs as expect ed when ne w function ality is i ntroduced into the s ystem unde r test. | |
415 | Section 50 8 Complian ce Testing | |
416 | A type of test that (1) ensure s that per sons with disabiliti es have ac cess to an d can inte ract with GUIs and ( 2) verifie s that the applicati on or syst em meets t he specifi ed Section 508 Compl iance stan dards. | |
417 | Security T esting | |
418 | A type of test that validates the securi ty require ments and to ensure readiness for the in dependent testing pe rformed by the Secur ity Assess ment Team as used by the Asses sment and Authorizat ion Proces s. | |
419 | Smoke Test ing | |
420 | A type of testing th at ensures that an a pplication or system is stable enough to enter tes ting in th e currentl y active t est phase. It is usu ally a sub set of the overall s et of test s, prefera bly automa ted, that touches pa rts of the system in at least a cursory way. | |
421 | System Tes ting | |
422 | System tes ting is th e testing of all par ts of an i ntegrated system, in cluding in terfaces t o external systems. Both funct ional and structural types of testing ar e performe d to verif y that the system pe rformance, operation and funct ionality a re sound. End to end testing w ith all in terfacing systems is the ultim ate versio n. | |
423 | Unit/Produ ct Compone nt Testing | |
424 | Product Co mponent Te sting (aka Unit Test ing) is th e internal technical and funct ional test ing of a m odule/comp onent of c ode. Produ ct Compone nt Testing verifies that the r equirement s defined in the det ail design specifica tion have been succe ssfully ap plied to t he module/ component under test . | |
425 | User Funct ional Test ing | |
426 | UFT is a t ype of Acc eptance Te st that in volves end -users tes ting the f unctionali ty of the applicatio n using te st data in a control led test e nvironment . |
Araxis Merge (but not the data content of this report) is Copyright © 1993-2016 Araxis Ltd (www.araxis.com). All rights reserved.