24. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 4/24/2018 3:32:50 PM Eastern Daylight 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.

24.1 Files compared

# Location File Last Modified
1 CPEE_v1_Build_7.zip\CPEE_v1_Build_7\Build 7 Deliverables CLIN_0008AE_CPE Project Build 7 Test Plan_v0.2.docx Tue Apr 24 15:18:40 2018 UTC
2 CPEE_v1_Build_7.zip\CPEE_v1_Build_7\Build 7 Deliverables CLIN_0008AE_CPE Project Build 7 Test Plan_v0.2.docx Tue Apr 24 18:53:10 2018 UTC

24.2 Comparison summary

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

24.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

24.4 Active regular expressions

No regular expressions were active.

24.5 Comparison detail

  1   Community  Care Syste ms Enhance ments (CCS E)
  2   Claims Pro cessing an d Eligibil ity (CP&E)  Enhanceme nts 
  3  
  4   Build 7 Te st Plan
  5  
  6  
  7  
  8  
  9  
  10  
  11   Department  of Vetera ns Affairs
  12   Office of  Informatio n and Tech nology (OI &T)
  13  
  14  
  15   February 2 018
  16   Version 0. 2
  17  
  18   Document V ersion and  Review Hi story
  19   Date
  20   Version
  21   Descriptio n
  22   Author
  23   Reviewed B y
  24   2/15/2018
  25   0.2
  26   Technical  Writer edi ts
  27   Loretta Wo ltz
  28   Faith Donn elly
  29   2/14/2018
  30   0.1
  31   Updated fo r Build 7
  32   Faith Donn elly
  33   Michael Sy nakiewcz
  34   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.
  35  
  36  
  37   Table of C ontents
  38  
  39   1.Introduc tion1
  40   1.1.Purpos e1
  41   1.2.Test O bjectives1
  42   1.3.Key Ro les and Re sponsibili ties2
  43   1.4.Proces ses and Re ferences2
  44   2.Items to  Be Tested 3
  45   2.1.Overvi ew of Test  Inclusion s3
  46   2.2.Overvi ew of Test  Exclusion s3
  47   3.Test Str ategy3
  48   3.1.Testin g Types4
  49   3.2.Produc tivity and  Support T ools4
  50   4.Test Cri teria5
  51   4.1.Proces s Reviews5
  52   4.2.Pass/F ail Criter ia5
  53   4.3.Suspen sion and R esumption  Criteria5
  54   4.4.Defini tion of Do ne6
  55   4.5.Accept ance Crite ria6
  56   5.Test Del iverables7
  57   6.Sprint S chedule7
  58   7.Test Env ironments7
  59   7.1.System  Hardware8
  60   7.2.System  Software  in the Tes t Environm ents8
  61   8.Dependen cies8
  62   9.Risks an d Constrai nts8
  63   10.Test Me trics10
  64   11.Glossar y10
  65   Appendix A  - Testing  Definitio ns12
  66  
  67  
  68  
  69   Introducti on
  70   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.
  71  
  72   The focus  of Build 7  is on Ven dor Stream lining and  utilizati on of the  Physical L ocation (P L) Zip Cod e. The Ven dor Stream lining pro cess, a ma nual proce ss carried  out in th e Image Pr ocessing ( IP) menu o ption by V E, is impo rtant for  several re asons: 
  73   Ensure tha t provider s who care  for benef iciaries a re paid fo r their se rvices in  a timely m anner 
  74   Ensure the  payment g oes to the  correct v endor 
  75   Verify pay -to provid er and ini tiate any  correction s to the v endor 
  76   Have new v endors or  locations  added to t he system,  (and ther eby, be ve rified by  the Vendor  Queue tea m)
  77   Reduce fra udulent an d errant r emit-to cl aims
  78   Improve th e overall  claims pro cessing sp eed and ac curacy
  79   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 Remi t-To (RT)  informatio n on the b ill. This  process en sures accu rate Civil ian Health  and Medic al Program  of the De partment o f Veterans  Affairs ( CHAMPVA) p ayment and  delivery  to the pro per billin g address.  
  80   Purpose
  81   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. 
  82   Test Objec tives
  83   This Build  Test Plan  supports  the follow ing object ives:
  84   Identify s cope for t he Build ( test activ ities)
  85   Identify t he test en vironment( s) for the  Build
  86   Validate s tatus and  stability  of test en vironment
  87   Support Us er Functio nal Testin g (UFT/UAT ) with Sub ject Matte r Experts  (SMEs) 
  88   Provide de fect repor ting and r esolution  process fo r the Buil d
  89   Key Roles  and Respon sibilities
  90   The follow ing table  lists the  key roles  that suppo rt the exe cution of  the Build  Test Plan.
  91   Table 1: K ey Roles a nd Descrip tions
  92   Role
  93   Descriptio n
  94   Developmen t Lead
  95   Person who  creates o r updates  the Busine ss Policy  or Busines s Rules
  96   Product Le ad
  97   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.
  98   Stakeholde rs
  99   Persons wh o hold a s take in a  situation  in which t hey may af fect or be  affected  by the out come.
  100   Test Team/ Testers
  101   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
  102   Configurat ion Manage ment
  103   Person who  establish es, mainta ins, and c ontrols te st environ ments.
  104   Business A nalyst
  105   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. 
  106   Processes  and Refere nces
  107   The proces ses that g uide the i mplementat ion of thi s Build Te st Plan ar e:
  108   Test Prepa ration
  109   Product Bu ild 
  110   Independen t Test and  Evaluatio n
  111   The refere nces that  support th e implemen tation of  this Build  Test Plan  are:
  112   Veteran Fo cused Inte gration Pr ocess (VIP )
  113   Performanc e Work Sta tement (PW S)
  114   Build Plan  
  115   Sprint Pla
  116   Business R equirement s Document  (BSM_CPEE _BRD_V02.0 0.00_Draft _Oct 2016)
  117   Items to B e Tested
  118   Overview o f Test Inc lusions
  119   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. 
  120  
  121   CP&E EPIC  001 Vendor  Streamlin ing (CR EN C022081):
  122   “As the He alth Claim s Reimburs ement grou p, I want  to match t he informa tion in ou r vendor f ile to the  informati on on the  claim so t hat I can  improve cl aim paymen t accuracy .”
  123   Overview o f Test Exc lusions
  124   The follow ing compon ents and f eatures, a nd combina tions of c omponents  and featur es, will n ot be test ed:
  125   No known e xclusions  at this ti me. Items  are identi fied durin g testing  and will b e captured  according ly.
  126   Test Strat egy
  127   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:
  128   Develop te st cases b ased on th e User Sto ries creat ed 
  129   Collaborat e with VA  Business S MEs
  130   Perform al l testing,  in the CP &E DEV Env ironment
  131   Perform Te st Readine ss Review  (TRR)   
  132   Execute te st cases a nd documen t test res ults 
  133   Log and re port test  defects fo r tracking  and resol ution
  134   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 Favor  TechConsu lting, LLC  (FTC) con tractors.  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.
  135   UNION Appr oval
  136   Notify Uni on Represe ntative(s)  of any ch anges in w orking con ditions 
  137   The Union  Representa tive(s) to  respond w ithin 14 d ays
  138   Dependency  is IT QA  completion  which wil l generate  the Stand ard Operat ing Proced ure (SOP)  needed to  begin UAT  and union  notificati on
  139   Union Repr esentative (s) will s end propos ed changes  to Union  members an d ask for  feedback a nd/or acce ptance 
  140   FTC will r espond to  any union  issues or  concerns d uring the  14 days
  141   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
  142   Obtain Uni on accepta nce 
  143   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
  144   Testing Ty pes
  145   This secti on describ es the pot ential typ es of test  activitie s to be pe rformed in  this proj ect. 
  146   Table 2: T est Types
  147   Test Types
  148   Party Resp onsible
  149   Unit/Produ ct/Compone nt Testing
  150   Developers /FTC SQA
  151   Functional  Testing
  152   FTC SQA
  153   Installati on Testing
  154   OIT/OCC
  155   Integratio n/System T esting
  156   Developers /FTC SQA
  157   Backend Te sting
  158   Developers /FTC SQA
  159   Regression  and Negat ive Testin g
  160   FTC SQA
  161   Section 50 8 Complian ce Testing
  162   FTC SQA 
  163   OCC QA and  User Func tional Tes ting (UFT/ UAT)
  164   OIT/OCC
  165  
  166   Productivi ty and Sup port Tools  
  167   This secti on describ es the too ls that wi ll be empl oyed to su pport this  Build Tes t Plan.
  168   Table 3: T ool Catego ry or Type s
  169   Tool Categ ory or Typ e
  170   Tool Brand  Name
  171   Defect Tra cking
  172   Rational Q uality Man ager (RQM)
  173   Project Ma nagement
  174   Rational D OORS Next  Generation  Requireme nts Manage ment (RDNG )
  175   Unit Testi ng
  176   J-Unit/M-U nit, RQM
  177   Configurat ion Manage ment
  178   Rational T eam Concer t (RTC) Co nfiguratio n and Chan ge Managem ent
  179   DBMS tools
  180   Fileman
  181   Functional  Testing
  182   RQM, Visua l Basic fo r Applicat ions (VBA) , Notepad
  183   Terminal E mulation S oftware
  184   Micro Focu s Reflecti on
  185   508 Compli ance
  186   JAWS
  187   Test Crite ria
  188   Process Re views
  189   The CP&E P roject Bui ld Test Pl an undergo es the fol lowing rev iews:
  190   Peer Revie w – Projec t Team pee r review u pon comple tion of th e draft Bu ild Test P lan
  191   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
  192   Pass/Fail  Criteria
  193   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.
  194   Suspension  and Resum ption Crit eria 
  195   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.
  196   Suspension  condition s include:
  197   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
  198   The test e nvironment  is corrup ted or ren dered unus able
  199   Project ma nagement d etermines  the need t o suspend  testing ba sed on som e other cr iteria
  200   Resumption  criteria  are:
  201   The condit ion that c aused the  suspension  is addres sed
  202   The change s are unit /component  tested
  203   The change s are appl ied to the  test envi ronment
  204   The initia l entry cr iteria of  the test p hase are m et
  205   Definition  of Done
  206   All requir ed testing  deliverab les will b e complete d, approve d by the c ustomer an d posted t o Rational .
  207  
  208   The follow ing criter ia will be  met for e ach User S tory inclu ded in thi s Build:
  209   Unit and S QA testing  completio n
  210   Acceptance  criteria  achievemen t for each  User Stor y tested
  211   All testin g phases c ompleted,  passed and  accepted  by the cus tomer
  212   All known  defects re solved or  documented  for resol ution in a  future Bu ild
  213   Acceptance  Criteria
  214   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.
  215   The testab le, functi onal requi rements fo r the Buil d must be  tested and  verified
  216   All defect s with a l evel of cr itical, hi gh and med ium are re solved, re tested and  closed
  217   Number of  Open Sev1  and Sev2 D efects = 0
  218   All defect s with a l evel of lo w are reso lved or pl aced in ba cklog for  future Bui ld 
  219   Percentage  of Sev3 o r lower De fects Open  < 10 
  220   All the te st cases a re execute d without  defects at  a medium  or higher  level 
  221   Number of  Blocked Ex ecution Re cords = 0,  Percentag e of Block ed Executi on Records  = 0%
  222   Number of  Failed Exe cution Rec ords = 0,  Percentage  of Failed  Execution  Records =  0% 
  223   Any outsta nding test  cases fro m a previo us test ru n have suc cessfully  passed
  224   The follow ing list r epresents  severity l evels, as  defined in  Rational:
  225   Severity 1
  226   Critical I mpact/Syst em Down
  227   Severity 2
  228   Significan t business  impact
  229   Severity 3
  230   Some busin ess impact
  231   Severity 4
  232   Minimal bu siness imp act
  233   Test Deliv erables
  234   Table 4 li sts the te st deliver ables for  the CP&E P roject.
  235   Table 4: T est Delive rables
  236   Test Deliv erables
  237   Frequency
  238   Build Test  Plan
  239   Per Build
  240   Test Resul ts and Exe cution Rep ort
  241   Per Sprint  in Ration al
  242   Test Cases /Test Scri pts
  243   Per Build  in Rationa l
  244   Defect Sta tus and Re solution
  245   Per Build/ As Needed
  246   Section 50 8 Complian ce Test Re sults
  247   Per Build/ As Appropr iate
  248   Traceabili ty Report  or Matrix
  249   Per Build/ As Needed
  250   Sprint Sch edule
  251   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. 
  252   Table 5: S print Sche dule
  253   Sprint #
  254   Start Date
  255   Finish Dat e
  256   Sprint 14
  257   2/28/18
  258   3/13/18
  259   Sprint 15
  260   3/14/18
  261   3/27/18
  262   Sprint 16
  263   3/28/18
  264   4/10/18
  265   Sprint 17
  266   4/11/18
  267   4/24/18
  268   Sprint 18
  269   4/25/18
  270   5/8/18
  271   Sprint 19
  272   5/9/18
  273   5/31/18
  274   Test Envir onments
  275   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. 
  276   The OCC pr oducts/sys tems plann ed to be m odified in  this Buil d are:
  277   CP&E
  278    System Ha rdware
  279   N/A
  280   System Sof tware in t he Test En vironments
  281  
  282   Table 6 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.
  283   Table 6: S oftware El ements
  284   Software E lement Nam e
  285   Version
  286   Type and O ther Notes
  287   CP&E DEV n amespace
  288  
  289   DNS.URL
  290   Dependenci es
  291   The follow ing depend encies and  constrain ts must be  considere d to succe ssfully ex ecute this  Build:
  292   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
  293   OCC busine ss resourc es are req uired to a nswer spec ific busin ess proces s and proc edure ques tions
  294   Coordinati on of code  deploymen t with the  Denver OC C
  295   HAC resour ce will be  required  to answer  specific t echnical q uestions r egarding d evelopment , testing  and implem entation i ssues. 
  296   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
  297   Risks and  Constraint s
  298   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.
  299  
  300   Risk Descr iption
  301   Potential  Impact of  Risk Reali zation
  302   Strategy -  avoid, ac cept or mi tigate
  303   Integrated  environme nt and/or  component,  including  the assoc iated netw ork connec tivity, ar e unavaila ble
  304   Impacts th e SQA Team ’s ability  to comple te their s cheduled t esting wit hin the ti meframe al located.
  305   Mitigate:
  306   Adjust tes t/work sch edules; wo rk with ex ternal gro ups to avo id outages
  307   If the ext ernal syst ems experi ence an ou tage, or p erform any  un-planne d refreshe s
  308   Impacts th e SQA sche dule
  309   Mitigate:
  310   Work close ly with ex ternal sys tems to en sure these  refreshes  or outage s are coor dinated wi thin the s chedule
  311   Requiremen ts deliver y late
  312   Risk to th e schedule  due to la te start b y developm ent
  313   Mitigate:
  314   Adjust tes t schedule ; compress  testing a ctivities;  request s chedule va riance
  315   Stakeholde r non-comp liance (de lays in si gn-off)
  316   Risk to th e final de livery dat e due to d elays in F ield Test  completion  or approv al to rele ase
  317   Mitigate:
  318   Maintain c lose conta ct with al l stakehol ders, keep ing them a pprised of  deadlines
  319   Working wi th Integra ted teams
  320   New system  version c an impact  testing an d schedule
  321   Mitigate:
  322   Coordinate ; communic ate with i ntegrated  teams and  plan ahead  so that s chedule wi ll be impa cted at a  minimum
  323   Potential  issues dur ing deploy ment of Bu ild
  324   Risk to th e schedule , potentia l delay in  Builds av ailable fo r testing
  325   Mitigate o r Accept
  326   Accept del ay
  327   Adjust tes t schedule ; compress  testing a ctivities;  request s chedule va riance
  328  
  329   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.
  330   This secti on lists i dentified  risks that  will like ly impact  the Build.  During th is Build,  risks and  issues wil l be track ed on the  PMO Risk R egister un til Ration al is full y set up a nd configu red for us e.
  331   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.
  332   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.
  333   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.
  334   Test Metri cs
  335   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. 
  336   Test metri cs may inc lude, but  are not li mited to:
  337   Number of  test cases  (pass/fai l)
  338   Percentage  of test c ases execu ted 
  339   Number of  requiremen ts and per centage te sted
  340   Percentage  of test c ases resul ting in de fect detec tion
  341   Number of  defects at tributed t o test cas e/test scr ipt creati on
  342   Percentage  of defect s identifi ed; listed  by cause  and severi ty
  343   Glossary
  344   Acronym
  345   Definition
  346   BRD
  347   Business R equirement s Document
  348   BSM
  349   Business S ystems Man agement
  350   CCSE
  351   Community  Care Syste m Enhancem ents
  352   CP&E
  353   Claims Pro cessing an d Eligibil ity
  354   CBOCC
  355   Central Bu siness Off ice Commun ity Care
  356   CHAMPVA
  357   Civilian H ealth and  Medical Pr ogram of t he Departm ent of Vet erans Affa irs
  358   CDR
  359   Clinical D ata Reposi tory
  360   DEV
  361   Developmen t
  362   EDI
  363   Electronic  Data Inte rchange 
  364   EPMO
  365   Enterprise  Program M anagement  Office
  366   ERA
  367   Electronic  Remittanc e Advice
  368   HAC
  369   Health Adm inistratio n Center
  370   IP
  371   Image Proc essing 
  372   OIT
  373   Office of  Informatio n Technolo gy
  374   OCC
  375   Office of  Community  Care
  376   PMO
  377   Program Ma nagement O ffice
  378   PWS
  379   Performanc e Work Sta tement
  380   RT
  381   Remit-To
  382   SME
  383   Subject Ma tter Exper t
  384   SQA
  385   Software Q uality Ass urance
  386   TRR
  387   Test Readi ness Revie
  388   UFT/UAT
  389   User Funct ional Test ing / User  Acceptanc e Test
  390   US
  391   Ultrasound
  392   VBA
  393   Visual Bas ic for App lications
  394   VA
  395   Department  of Vetera ns Affairs
  396   VE
  397   Voucher Ex aminer 
  398   VistA
  399   Veterans H ealth Info rmation Sy stems and  Technology  Architect ure
  400  
  401  
  402   Appendix A  - Testing  Definitio ns 
  403  
  404   Test Type 
  405   Definition  
  406   Backend Te sting
  407   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.  
  408   Functional  Testing
  409   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.
  410   Installati on Testing  
  411   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. 
  412   Integratio n Testing 
  413   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).  
  414   Load Testi ng 
  415   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 ).
  416   Performanc e Testing 
  417   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.  
  418   Regression  Testing
  419   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.  
  420   Section 50 8 Complian ce Testing  
  421   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. 
  422   Security T esting 
  423   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. 
  424   Smoke Test ing
  425   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.  
  426   System Tes ting 
  427   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.  
  428   Unit/Produ ct Compone nt Testing  
  429   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
  430   User Funct ional Test ing
  431   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 .