287. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 11/9/2018 12:34:25 AM Central 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.

287.1 Files compared

# Location File Last Modified
1 CPEE_Build9_Sprint27.zip CCSE CPE Build 9 Test Plan.docx Mon Nov 5 16:38:36 2018 UTC
2 CPEE_Build9_Sprint27.zip CCSE CPE Build 9 Test Plan.docx Fri Nov 9 03:58:59 2018 UTC

287.2 Comparison summary

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

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

287.4 Active regular expressions

No regular expressions were active.

287.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 9 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   July 2018
  16   Version 0. 1
  17  
  18   Document V ersion and  Review Hi story
  19   Date
  20   Version
  21   Descriptio n
  22   Author
  23   Reviewed B y
  24   7/18/2018
  25   0.1
  26   CPE Build  9 Test Pla n Initial  Version
  27   Diane Stin son
  28   Michael Sy nakiewcz
  29   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.
  30  
  31  
  32   Table of C ontents
  33  
  34   1.Introduc tion1
  35   1.1.Purpos e1
  36   1.2.Test O bjectives1
  37   1.3.Key Ro les and Re sponsibili ties1
  38   1.4.Proces ses and Re ferences2
  39   2.Items to  Be Tested 2
  40   2.1.Overvi ew of Test  Inclusion s2
  41   2.2.Overvi ew of Test  Exclusion s3
  42   3.Test Str ategy3
  43   3.1.Testin g Types4
  44   3.2.Produc tivity and  Support T ools4
  45   4.Test Cri teria5
  46   4.1.Proces s Reviews5
  47   4.2.Pass/F ail Criter ia5
  48   4.3.Suspen sion and R esumption  Criteria5
  49   4.4.Defini tion of Do ne5
  50   4.5.Accept ance Crite ria6
  51   5.Test Del iverables6
  52   6.Sprint S chedule7
  53   7.Test Env ironments7
  54   7.1.System  Hardware7
  55   7.2.System  Software  in the Tes t Environm ents7
  56   8.Dependen cies8
  57   9.Risks an d Constrai nts8
  58   10.Test Me trics9
  59   11.Glossar y10
  60   Appendix A  - Testing  Definitio ns12
  61  
  62  
  63  
  64   Introducti on
  65   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.
  66  
  67   The focus  of Build 9  is on enr ollment an d eligibil ity status  of Spina  Bifida (SB ) benefici aries in C P&E. The C P&E system  should al low an SB  beneficiar y to dis-e nroll and  re-enroll  from the S B program,  as well a s provide  specific e ligibility  status, a s it does  for Civili an Health  and Medica l Program  of the Dep artment of  Veteran A ffairs (CH AMPVA) ben eficiaries .  The sys tem should  also prov ide an acc urate elig ibility st atus for a n SB benef iciary. An y status u pdates sho uld be rec orded in t he Edit Be neficiary  screen for  historica l purposes .
  68    
  69   Purpose
  70   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. 
  71   Test Objec tives
  72   This Build  Test Plan  supports  the follow ing object ives:
  73   Identify s cope for t he Build ( test activ ities)
  74   Identify t he test en vironment( s) for the  Build
  75   Validate s tatus and  stability  of test en vironment
  76   Support Us er Functio nal Testin g/User Acc eptance Te sting (UFT /UAT) with  Subject M atter Expe rts (SMEs)  
  77   Provide de fect repor ting and r esolution  process fo r the Buil d
  78   Key Roles  and Respon sibilities
  79   The follow ing table  lists the  key roles  that suppo rt the exe cution of  the Build  Test Plan.
  80   Table 1: K ey Roles a nd Descrip tions
  81   Role
  82   Descriptio n
  83   Developmen t Lead
  84   Person who  creates o r updates  the Busine ss Policy  or Busines s Rules.
  85   Product Le ad
  86   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.
  87   Stakeholde rs
  88   Persons wh o hold a s take in a  situation  in which t hey may af fect or be  affected  by the out come.
  89   Test Team/ Testers
  90   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.
  91   Configurat ion Manage ment (CM)
  92   Person who  establish es, mainta ins, and c ontrols te st environ ments.
  93   Business A nalyst
  94   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. 
  95   Processes  and Refere nces
  96   The proces ses that g uide the i mplementat ion of thi s Build Te st Plan ar e:
  97   Test Prepa ration
  98   Product Bu ild 
  99   Independen t Test and  Evaluatio n
  100   The refere nces that  support th e implemen tation of  this Build  Test Plan  are:
  101   Veteran Fo cused Inte gration Pr ocess (VIP )
  102   Performanc e Work Sta tement (PW S)
  103   Build Plan  
  104   Sprint Pla
  105   Business R equirement s Document  (BRD)
  106   BSM_CPEE_B RD_V02.00. 00_Draft_O ct 2016
  107   Items to B e Tested
  108   Overview o f Test Inc lusions
  109   CP&E Proje ct testing  is develo ped based  on the pro duct backl og from th e BRD, dir ection fro m the cust omer, as w ell as cha nge reques ts submitt ed by the  Central Bu siness Off ice Commun ity Care ( CBOCC) use rs over th e course o f months a nd years a re reviewe d and prio ritized as  part of t he ongoing  operation s and main tenance of  the backl og for the  CP&E syst em. 
  110  
  111   ACA_Disenr ollment EP IC 001 ACE  Disenroll ment for C HAMPVA (CV A) and Spi na Bifida  (SB) Famil y Members
  112   “As an Eli gibility a nd Enrollm ent Verifi cation (EE V) group,  I need the  ability t o disenrol l family m embers fro m the CVA  and/or SB  Programs e ven though  they meet  all eligi bility cri teria.”
  113   Overview o f Test Exc lusions
  114   The follow ing compon ents and f eatures, a nd combina tions of c omponents  and featur es, will n ot be test ed:
  115   No known e xclusions  at this ti me. Items  are identi fied durin g testing  and will b e captured  according ly.
  116   Test Strat egy
  117   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:
  118   Develop te st cases b ased on th e User Sto ries creat ed 
  119   Collaborat e with VA  Business S MEs
  120   Perform al l testing,  in the CP &E DEV Env ironment
  121   Perform Te st Readine ss Review  (TRR)   
  122   Execute te st cases a nd documen t test res ults 
  123   Log and re port test  defects fo r tracking  and resol ution
  124   Upon deliv ery of the  code to t he Denver  Office of  Community  Care (OCC)  Quality A ssurance ( QA) Depart ment, test ing perfor med by the  QA team w ill have s upport fro m Favor Te chConsulti ng, LLC (F TC) contra ctors. UFT /UAT testi ng will be  performed  after QA  is complet e. Both QA  and UFT/U AT anticip ate the ne ed for app roximately  30 to 45  business d ays each t o finalize  testing e fforts.
  125   UNION Appr oval
  126   Notify Uni on Represe ntative(s)  of any ch anges in w orking con ditions 
  127   The Union  Representa tive(s) to  respond w ithin 14 d ays
  128   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
  129   Union Repr esentative (s) will s end propos ed changes  to Union  members an d ask for  feedback a nd/or acce ptance 
  130   FTC will r espond to  any union  issues or  concerns d uring the  14 days
  131   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
  132   Obtain Uni on accepta nce 
  133   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
  134   Testing Ty pes
  135   This secti on describ es the pot ential typ es of test  activitie s to be pe rformed in  this proj ect. 
  136   Table 2: T est Types
  137   Test Types
  138   Party Resp onsible
  139   Unit/Produ ct/Compone nt Testing
  140   Developers /FTC Softw are Qualit y Assuranc e (SQA)
  141   Functional  Testing
  142   FTC SQA
  143   Installati on Testing
  144   OI&T/OCC
  145   Integratio n/System T esting
  146   Developers /FTC SQA
  147   Backend Te sting
  148   Developers /FTC SQA
  149   Regression  and Negat ive Testin g
  150   FTC SQA
  151   Section 50 8 Complian ce Testing
  152   FTC SQA 
  153   OCC QA and  UFT/UAT
  154   OIT/OCC
  155  
  156   Productivi ty and Sup port Tools  
  157   This secti on describ es the too ls that wi ll be empl oyed to su pport this  Build Tes t Plan.
  158   Table 3: T ool Catego ry or Type s
  159   Tool Categ ory or Typ e
  160   Tool Brand  Name
  161   Defect Tra cking
  162   Rational Q uality Man ager (RQM)
  163   Project Ma nagement
  164   Rational D OORS Next  Generation  Requireme nts Manage ment (RDNG )
  165   Unit Testi ng
  166   J-Unit/M-U nit, RQM
  167   CM
  168   Rational T eam Concer t (RTC) Co nfiguratio n and Chan ge Managem ent
  169   Database M anagement  Software ( DBMS) tool s
  170   Fileman
  171   Functional  Testing
  172   RQM, Visua l Basic fo r Applicat ions (VBA) , Notepad
  173   Terminal E mulation S oftware
  174   Micro Focu s Reflecti on
  175   508 Compli ance
  176   Job Access  With Spee ch (JAWS)
  177   Test Crite ria
  178   Process Re views
  179   The CP&E P roject Bui ld Test Pl an undergo es the fol lowing rev iews:
  180   Peer Revie w – Projec t Team pee r review u pon comple tion of th e draft Bu ild Test P lan
  181   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
  182   Pass/Fail  Criteria
  183   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.
  184   Suspension  and Resum ption Crit eria 
  185   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 OIT  Program Ma nagement O ffice (PMO ) Technica l Leads wi ll discuss  the impac t of the d efect and  determine  whether to  suspend t esting and , if so, w hich produ ct areas a re affecte d. The tes t suspensi on causes  testing to  be suspen ded or blo cked until  the FTC d evelopers  and tester s can inst all and un it test a  fix or wor k-around.
  186   Suspension  condition s include:
  187   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
  188   The test e nvironment  is corrup ted or ren dered unus able
  189   Project ma nagement d etermines  the need t o suspend  testing ba sed on som e other cr iteria
  190   Resumption  criteria  are:
  191   The condit ion that c aused the  suspension  is addres sed
  192   The change s are unit /component  tested
  193   The change s are appl ied to the  test envi ronment
  194   The initia l entry cr iteria of  the test p hase are m et
  195   Definition  of Done
  196   All requir ed testing  deliverab les will b e complete d, approve d by the c ustomer an d posted t o Rational .
  197  
  198   The follow ing criter ia will be  met for e ach User S tory inclu ded in thi s Build:
  199   Unit and S QA testing  completio n
  200   Acceptance  criteria  achievemen t for each  User Stor y tested
  201   All testin g phases c ompleted,  passed and  accepted  by the cus tomer
  202   All known  defects re solved or  documented  for resol ution in a  future Bu ild
  203   Acceptance  Criteria
  204   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.
  205   The testab le, functi onal requi rements fo r the Buil d must be  tested and  verified
  206   All defect s with a l evel of cr itical, hi gh and med ium are re solved, re tested and  closed
  207   Number of  Open Sev1  and Sev2 D efects = 0
  208   All defect s with a l evel of lo w are reso lved or pl aced in ba cklog for  future Bui ld 
  209   Percentage  of Sev3 o r lower De fects Open  < 10 
  210   All the te st cases a re execute d without  defects at  a medium  or higher  level 
  211   Number of  Blocked Ex ecution Re cords = 0,  Percentag e of Block ed Executi on Records  = 0%
  212   Number of  Failed Exe cution Rec ords = 0,  Percentage  of Failed  Execution  Records =  0% 
  213   Any outsta nding test  cases fro m a previo us test ru n have suc cessfully  passed
  214   The follow ing list r epresents  severity l evels, as  defined in  Rational:
  215   Severity 1
  216   Critical I mpact/Syst em Down
  217   Severity 2
  218   Significan t business  impact
  219   Severity 3
  220   Some busin ess impact
  221   Severity 4
  222   Minimal bu siness imp act
  223   Test Deliv erables
  224   Table 4 li sts the te st deliver ables for  the CP&E P roject.
  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  in Ration al
  232   Test Cases /Test Scri pts
  233   Per Build  in Rationa l
  234   Defect Sta tus and Re solution
  235   Per Build/ As Needed
  236   Section 50 8 Complian ce Test Re sults
  237   Per Build/ As Appropr iate
  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 24
  247   8/01/18
  248   8/14/18
  249   Sprint 25
  250   8/15/18
  251   8/28/18
  252   Sprint 26
  253   8/29/18
  254   9/11/18
  255   Sprint 27
  256   9/12/18
  257   9/27/18
  258   Test Envir onments
  259   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 OCC. Th e Denver O CC will be  responsib le for con figuring a nd maintai ning the t est enviro nments. 
  260   The OCC pr oducts/sys tems plann ed to be m odified in  this Buil d are:
  261   CP&E
  262    System Ha rdware
  263   Not applic able (N/A) .
  264   System Sof tware in t he Test En vironments
  265  
  266   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.
  267   Table 6: S oftware El ements
  268   Software E lement Nam e
  269   Version
  270   Type and O ther Notes
  271   CP&E DEV n amespace
  272  
  273   testecp-ha d.hac.med. va.gov
  274   Dependenci es
  275   The follow ing depend encies and  constrain ts must be  considere d to succe ssfully ex ecute this  Build:
  276   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
  277   OCC busine ss resourc es are req uired to a nswer spec ific busin ess proces s and proc edure ques tions
  278   Coordinati on of code  deploymen t with the  Denver OC C
  279   HAC resour ce will be  required  to answer  specific t echnical q uestions r egarding d evelopment , testing  and implem entation i ssues. 
  280   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
  281   Risks and  Constraint s
  282   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.
  283  
  284   Risk Descr iption
  285   Potential  Impact of  Risk Reali zation
  286   Strategy -  avoid, ac cept or mi tigate
  287   Integrated  environme nt and/or  component,  including  the assoc iated netw ork connec tivity, ar e unavaila ble
  288   Impacts th e SQA Team ’s ability  to comple te their s cheduled t esting wit hin the ti meframe al located.
  289   Mitigate:
  290   Adjust tes t/work sch edules; wo rk with ex ternal gro ups to avo id outages
  291   If the ext ernal syst ems experi ence an ou tage, or p erform any  un-planne d refreshe s
  292   Impacts th e SQA sche dule
  293   Mitigate:
  294   Work close ly with ex ternal sys tems to en sure these  refreshes  or outage s are coor dinated wi thin the s chedule
  295   Requiremen ts deliver y late
  296   Risk to th e schedule  due to la te start b y developm ent
  297   Mitigate:
  298   Adjust tes t schedule ; compress  testing a ctivities;  request s chedule va riance
  299   Stakeholde r non-comp liance (de lays in si gn-off)
  300   Risk to th e final de livery dat e due to d elays in F ield Test  completion  or approv al to rele ase
  301   Mitigate:
  302   Maintain c lose conta ct with al l stakehol ders, keep ing them a pprised of  deadlines
  303   Working wi th Integra ted teams
  304   New system  version c an impact  testing an d schedule
  305   Mitigate:
  306   Coordinate ; communic ate with i ntegrated  teams and  plan ahead  so that s chedule wi ll be impa cted at a  minimum
  307   Potential  issues dur ing deploy ment of Bu ild
  308   Risk to th e schedule , potentia l delay in  Builds av ailable fo r testing
  309   Mitigate o r Accept
  310   Accept del ay
  311   Adjust tes t schedule ; compress  testing a ctivities;  request s chedule va riance
  312  
  313   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.
  314   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.
  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 .