4. EPMO Open Source Coordination Office Redaction File Detail Report

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.

4.1 Files compared

# 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

4.2 Comparison summary

Description Between
Files 1 and 2
Text Blocks Lines
Unchanged 1 852
Changed 0 0
Inserted 0 0
Removed 0 0

4.3 Comparison options

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

4.4 Active regular expressions

No regular expressions were active.

4.5 Comparison detail

  1   Community  Care Syste ms Enhance ments (CCS E)
  2   Claims Pro cessing an d Eligibil ity (CP&E)  Enhanceme nts Build 
  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
  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
  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
  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 .