14. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 2/15/2018 2:12:56 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.

14.1 Files compared

# Location File Last Modified
1 CPEE_Build_6_Sprint_9 and 11.zip CLIN_0008AE_CPE Build 6 Test Plan_v0.1.docx Tue Feb 6 17:50:58 2018 UTC
2 CPEE_Build_6_Sprint_9 and 11.zip CLIN_0008AE_CPE Build 6 Test Plan_v0.1.docx Wed Feb 14 22:18:07 2018 UTC

14.2 Comparison summary

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

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

14.4 Active regular expressions

No regular expressions were active.

14.5 Comparison detail

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