73. EPMO Open Source Coordination Office Redaction File Detail Report

Produced by Araxis Merge on 12/8/2017 1:33:43 PM 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.

73.1 Files compared

#	Location	File	Last Modified
1	PC_CP4_CiF.zip	CLIN_0008AE_CCEDI Build 3 Test Plan_09222017.doc	Fri Dec 8 18:05:02 2017 UTC
2	PC_CP4_CiF.zip	CLIN_0008AE_CCEDI Build 3 Test Plan_09222017.doc	Fri Dec 8 19:25:17 2017 UTC

73.2 Comparison summary

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

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

73.4 Active regular expressions

No regular expressions were active.

73.5 Comparison detail

	1	Master Tes t Plan Tem plateCommu nity Care Electronic Data Inte rchange
	2	(CCEDI)
	3	Build 3 T est Plan
	4
	5	Department of Vetera ns Affairs
	6	Office of Informatio n and Tech nology (OI &T)
	7	September 2017
	8	Version 0. 5
	9	Document V ersion His tory
	10	DateVersio nDescripti onAuthor09 /22/20170. 5Technical EditLoret ta Woltz09 /21/20170. 4 Technica l ReviewJo sh Lone09/ 21/20170.3 Introducti on ReviewG eorge Brit tingham09/ 20/20170.2 Draft Revi ewRaymond Bridges09/ 19/20170.1 Draft Jose Pulickath adamThe do cument ver sion histo ry will be used to t rack docum ent change s througho ut the cyc le of the product pl anning pro cess. Plea se note th at the mos t recent r evision en try is at the top of the table .
	11	Table of C ontents
	12	11.
	13	Introducti on
	14
	15	1.1.
	16	Purpose
	17	1
	18	1.2.
	19	Test Objec tives
	20	1
	21	1.3.
	22	Roles and Responsibi lities
	23	2
	24	1.4.
	25	Processes and Refere nces
	26	2
	27	2.
	28	Items to B e Tested
	29	3
	30	2.1.
	31	Overview o f Test Inc lusions fo r Build 3
	32	3
	33	3.
	34	Test Appro ach
	35	4
	36	4.
	37	Testing Ty pes and To ols
	38	4
	39	4.1.
	40	Test Types
	41	4
	42	4.2.
	43	Productivi ty and Sup port Tools
	44	5
	45	5.
	46	Test Crite ria
	47	6
	48	5.1.
	49	Process Re views
	50	6
	51	5.2.
	52	Pass/Fail Criteria
	53	6
	54	5.3.
	55	Suspension and Resum ption Crit eria
	56	6
	57	5.4.
	58	Acceptance Criteria
	59	6
	60	6.
	61	Test Deliv erables
	62	7
	63	7.
	64	Test Sched ule
	65	7
	66	8.
	67	Test Envir onments
	68	8
	69	8.1.
	70	System Har dware
	71	8
	72	9.
	73	System Sof tware in t he Test En vironments
	74	8
	75	9.1.
	76	Dependenci es
	77	9
	78	10.
	79	Risks and Constraint s
	80	10
	81	11.
	82	Test Metri cs
	83	11
	84	12.
	85	Acronyms
	86	11
	87	Appendix - Test Type Definitio ns
	88	12
	89
	90
	91	Introducti on
	92	The Commun ity Care E lectronic Data Inter change (CC EDI) proje ct address es technic al systems residing in the Hea lth Admini stration C enter (HAC ) under th e Office o f Informat ion and Te chnology ( OI&T). The project o bjective i s to addre ss and cor rect secur ity defici encies in software a pplication s, ensure compliance with 508 standards, establish disaster recovery p rocedures and report ing proces ses, and e xpand HAC environmen t testing capabiliti es. The se curity asp ects of th is project include i ncreased t esting sec urity func tionality in EDI Web Viewer (E WV), Fee P ayment Pro cessing Sy stem (FPPS ) front an d back-end upgrades, and prede fined/cust omized rep orting.
	93	This Build Test Plan outlines the high-l evel strat egy to be implemente d by Favor TechConsu lting (FTC ) to succe ssfully ma nage Commu nity Care (CC) Elect ronic Data Interchan ge (EDI) B uild 3. Th is is the third inst allment of the FPPS Upgrade de velopment, ultimatel y resultin g in the f irst incre mental rel ease of th e new FPPS applicati on.
	94	The goal o f Build 3 is to comp lete the f irst incre mental rel ease of th e upgraded FPPS appl ication, i mplement O HI functio nality tha t is new t o FPPS, an d complete the funct ionality t hat a Read -Only user will be a ble to uti lize. The functional ity implem ented will expand up on the arc hitecture that was i mplemented in Build 1 and 2. E nd-to-End integratio n will inc lude the f rontend an d backend servers wi th a datab ase that i s populate d with the minimum a mount of m ock data n eeded to d emonstrate completio n of the d evelopment effort.
	95	Given the replacemen t of found ational fr ameworks a nd the rel ated requi rements fo r Security , Performa nce, 508 C ompliance, Testing a nd Reporti ng, the CC EDI effort is the cr eation of new enterp rise-level claims pr ocessing s oftware. T his soluti on will be modern, s calable an d extensib le. A soli d applicat ion base w ill allow more rapid developme nt and dep loyment of end user screens.
	96	Purpose
	97	The purpos e of the B uild Test Plan for t he FPPS Fr ont-End wo rkstream d eliverable s is to de scribe the overall a pproach i. e., define s the test levels an d types of tests pla nned throu ghout the project li fe cycle, including testing ac tivities, resources to perform those act ivities, s chedule of test acti vities, as signed res ponsibilit ies, and r esources r equired to determine readiness of the bu ild.
	98	Test Objec tives
	99	This Build Test Plan supports the follow ing object ives for C CEDI FPPS Project:
	100	Provide te st approac h for Buil d 3
	101	Identify s cope and t est enviro nment(s) f or the Bui ld
	102	Support Us er Functio nal Testin g (UFT/UAT ) with Sub ject Matte r Experts (SMEs)
	103	Provide th e defect r eporting a nd resolut ion proces s for the Build
	104	Roles and Responsibi lities
	105	The follow ing table lists the key roles that suppo rt the exe cution of the Build Test Plan.
	106	Table 1: R oles and D escription s
	107	RoleDescri ptionDevel opment Tea mPersons w ho create or update the Busine ss Policy or Busines s Rules.Sc rum Master Leads all Agile cere monies: S print Plan ning, Dail y Scrum, S print Revi ew, Sprint Retrospec tive, and Backlog Re finementTe chnical Le adPerson w ho has ove rall respo nsibility for techni cal questi ons and ov ersight.Pr oduct Lead Person who has overa ll respons ibility fo r the succ essful pla nning and execution of a proje ct; person responsib le for cre ating the Build Test Plan in c ollaborati on with th e Developm ent Lead.S takeholder sPersons w ho hold a stake in a situation in which they may a ffect or b e affected by the ou tcome.Busi ness Analy stPerson w ho analyze s the busi ness proce ss and its integrati on with th e technolo gy.Test Le adPerson r esponsible for ensur ing full e xecution o f the test process t o include the verifi cation of technical requiremen ts and the validatio n of busin ess requir ements. Le ads and co ordinates activities related t o all aspe cts of tes ting based on an app roved Buil d Test Pla n and sche dule.Test Team/Teste rsPersons who execut e tests an d ensure t he test en vironment will adequ ately supp ort planne d test act ivities. R esponsible for assis ting with the creati on and imp lementatio n of the B uild Test Plan.Confi guration M anagementP erson invo lved Sourc e Control Management , Code Dep loyments, Environmen t Configur ation and resident R ational Te am Concert expert.HA C QA Testi ngQuality Assurance TestingUFT /UAT Testi ngUser Fun ctional/ U ser Accept ance Testi ngProcesse s and Refe rences
	108	The proces ses that g uide the i mplementat ion of thi s Build Te st Plan ar e:
	109	Test Prepa ration
	110	Product Bu ild
	111	Independen t Test and Evaluatio n
	112	The refere nces that support th e implemen tation of this Build Test Plan are:
	113	VIP
	114	Performanc e Work Sta tement (PW S)
	115	Build Plan
	116	Business R equirement s Document (BSM_EDI- PCSI_BRD_V 01.01.04_O ct 2016) < BSM_EDI-PC SI_BRD_V01 .00.00>
	117	Items to B e Tested
	118	Overview o f Test Inc lusions fo r Build 3
	119	Testing of FPPS Buil d 3 items is develop ed from ch ange reque sts submit ted by FPP S Security Upgrade C OB (coordi nation of benefits) case adjud ication te am. FTC te am will de velop item s to test that will include th e followin g for Buil d 3
	120	PCSI Epic 002 <89403 7>
	121	“As VHA C C, I want to upgrade FPPS to m eet curren t security requireme nts while maintainin g existing functiona lity so th at I can c ontinue to use curre nt process es in the system.”
	122	Sub-epic 0 01 of PCSI TRM <8940 38>
	123	“AS the VH A CC, I ne ed FPPS to utilize T RM-complia nt technol ogies, so that I can achieve A uthority t o Operate (ATO).”
	124	Sub-epic 0 02 of PCSI TRM <8940 45>
	125	“AS the VH A CC, I ne ed FPPS to maintain existing e nd-user fu nctionalit y, so that there is no loss in business continuity due to en d-user ret raining.”
	126	Table 2: B uild 3 Sub -Epics
	127	Rational R eference # Sub-Epics Primary Te xtAcceptan ce Criteri aSprint894 041005: A s an FPPS Claims Pro cessor I n eed to hav e OHI Data available for revie w within t he FPPS ap plication so that I can make a ccurate de cisions on claim adj udication. View OHI d ata from w ithin the FPPS Appli cation.1/2 909736033: As an FP PS Admin, I need a C laim Disap proval pag e, so I th at I can d isapprove claims.Vie w FPPS Cla im Disappr oval page. 191103104 3: As an FPPS Admin , I need a Station M aintenance - Add Pag e, so I th at I can a dd station informati on.View St ation Main tenance - Add Page.1 911112044: As an FP PS Admin, I need a S tation Mai ntenance - Edit Page , so I tha t I can ed it station informati on.View St ation Main tenance - Edit Page. 1/29111820 45: As an FPPS Admi n, I need a Station Maintenanc e - View P age, so I that I can view stat ion inform ation.View Station M aintenance - View Pa ge.2911235 047: As a n FPPS Adm in, I need an Add Zi p Code Pag e, so I th at I can a dd a zip c ode to a s tation.Vie w FPPS Sta tion Maint enance - A dd Zip Cod e Page.291 2852058.10 : As a FP PS Admin, I need to have a Rea d Only Use r Role so that FPPS users have minimum a ppropriate permissio ns.Verify that a use r assigned the Read Only User Role can a ccess the FPPS produ ct.1/29160 13063: As an FPPS A dmin, I ne ed a Manua l Reconcil iation - O ut of Syst em Payment Page, so that I can apply pay ments to c laim line items when manually reconcilin g claims.V iew Manual Reconcili ation - Ou t of Syste m Payment Page.1/2Te st Approac h
	128	Test appro ach sectio n details the tests for the FP PS develop ment team and projec t stakehol ders plan to cover f or the bui lds planne d for this workstrea m. Test ap proach inc ludes foll owing step s:
	129	1. Develop Build Tes t Plan. Re view the B uild Test Plan with Testing St akeholders and obtai n approval .
	130	2. Perform Test Read iness Revi ew
	131	3. Develop Test Case s based on the User Stories de veloped fo r build 3 and in col laboration with Subj ect Matter Experts ( SMEs).
	132	4. Perform Continuou s Integrat ion (CI) T esting usi ng Jenkins server
	133	5. Execute test case s and docu ment the t est result s
	134	6. Perform all Testi ng of the FPPS Proje ct develop ed for Bui ld 3 in th e Developm ent Enviro nment
	135	7. Log and report te st defects for defec t resoluti on
	136	Testing Ty pes and To ols
	137	Test Types
	138	This secti on describ es the typ es of test activitie s to be pe rformed in this work stream.
	139	Table 3: T est Types
	140	Test Types Party Resp onsibleCom mentsUnit TestingFTC Developer sWith code coverage and intern al peer re viewIntegr ation Test ingVA and FTC Develo pers (with constrain ts)VA to p erform ful l integrat ion testin g, FTC usi ng mock da ta and no external i nterfacesB ackend Tes tingFTC SQ ARegressio n TestingF TC SQAFunc tional Tes tingFTC SQ AHAC QA Te stingVAUFT /UAT Testi ng VA
	141	User Funct ional/Acce ptance Tes tingSecuri ty Testing VA508 Comp liance Tes tingFTC SQ A and VA O CC QA Test ingVAProdu ctivity an d Support Tools
	142	This secti on describ es the too ls that wi ll be empl oyed to su pport this Build Pla n.
	143	Table 4: T ool Catego ry or Type s
	144	Tool Categ ory or Typ eTool Bran d NameDefe ct Trackin gRational Quality Ma nager (RQM )Unit Test ingJUnit, Rational Q uality Man agerConfig uration Ma nagementRa tional Tea m Concert Configurat ion and Ch ange Manag ementDBMS toolsToadF unctional TestingRat ional Qual ity Manage r (RQM), S elenium an d SoapUISe curity Tes tingFortif y508 Compl iance Test ingJAWSCon tinuous In tegration (CI) Jenki ns, Gradle Test Crite ria
	145	Process Re views
	146	The Build Test Plan under goes two revie ws:
	147	Peer Revie w – Testin g peer rev iew upon c ompletion of the dra ft Build T est Plan
	148	Formal Rev iew –Produ ct Manager reviews a nd approve s the Buil d Test Pla n
	149	Pass/Fail Criteria
	150	An item or test case will be c onsidered to pass if it meets the busine ss’ requir ements in an accepta ble manner and/or ha s an accep table work -around, w hich has b een approv ed by all project st akeholders . An item or test ca se will fa il if it d oes not me et the bus iness’ req uirements in an acce ptable man ner and/or does not have an ac ceptable w ork-around approved by all pro ject stake holders.
	151	Suspension and Resum ption Crit eria
	152	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 Te chnical Le ad from FT C and PMO will discu ss the imp act of the defect an d determin e whether to suspend testing a nd, if so, which pro duct areas are affec ted. The t est suspen sion cause s testing to be susp ended or b locked unt il the FTC developer s and test ers can in stall and unit test a fix or w ork-around .
	153	Suspension condition s include:
	154	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
	155	The test e nvironment is corrup ted or ren dered unus able
	156	Project ma nagement d etermines the need t o suspend testing ba sed on som e other cr iteria
	157	Resumption criteria are:
	158	The condit ion that c aused the suspension is addres sed
	159	The change s are unit /component tested
	160	The change s are appl ied to the test envi ronment
	161	The initia l entry cr iteria of the test p hase are m et
	162	Acceptance Criteria
	163	Business P olicy deve loped for FPPS Front -End works tream must meet the following criteria
	164	to be acce pted:
	165	The testab le, functi onal requi rements fo r the buil d must be tested and verified
	166	All defect s with a p riority le vel of cri tical, hig h and medi um are res olved, ret ested and closed
	167	All defect s with a p riority le vel of low are resol ved or cha nged to a defect res olution
	168	level of f uture rele ase
	169	Any outsta nding test cases fro m a previo us test ru n have suc cessfully passed
	170	All the te st cases a re execute d without defects at a medium or higher level
	171	Test Deliv erables
	172	Table 5 li sts the te st deliver ables for the FPPS P CSI workst ream.
	173	Table 5: T est Delive rables
	174	Test Deliv erablesRes ponsible P artyBuild Test PlanF TC SQATest Results/E xecution i n Rational FTC SQATes t Cases/Te st Scripts FTC SQATra ceability Report or MatrixFTC SQADefect status and Resolutio nFTC SQATe st Schedul e
	175	This secti on lists t he testing schedule for FPPS F ront-End w orkstream. Note: Sin ce this is an agile developmen t project, it goes b y each spr int.
	176	Table 6: T esting Sch edule
	177	Build 3 Sc heduleStar t DateEnd DateSprint 1Thu 9/28 /17Tue 10/ 10/17Sprin t 2Wed 10/ 11/17Tue 1 0/24/17Spr int 3Wed 1 0/25/17Tue 11/7/17Sp rint 4Wed 11/8/17Tue 11/21/17S print 5Wed 11/22/17T ue 12/5/17 Sprint 6We d 12/6/17T ue 12/19/1 7Test Envi ronments
	178	The develo pment and test envir onment, as well as C ontinuous Integratio n and Test (CI&T) fo r the CCED I FPPS Fro nt-End and Back-End upgrades w ill reside in the En terprise D evelopment Environme nt (EDE). A remote d atabase co nnection w ill be mad e from the EDE to th e HAC. Dat a for CI&T will be r ead from a n Oracle i nstance co ntaining E _REPOS and FPPS_OWNE R data.
	179	The party or parties responsib le for con figuring a nd maintai ning the t est enviro nments are :
	180	Responsibl e PartyRol eJoshua Lo neCI/CM Bu ild LeadDa vid Rosenf eldCM Lead System Ha rdware
	181	The follow ing table describes the base h ardware el ements tha t are requ ired in th e test env ironment f or this Bu ild Test P lan.
	182	Table 7: S ystem Hard ware Resou rces
	183	ResourceQu antityName and TypeB uild Serve r (Jenkins ): REDACTED 1 REDACTED - CentOS 7.3Web App Server #1 (DEV) REDACTED 1 REDACTED - CentOS 7.3Web App Server #2 (QA) REDACTED 1 REDACTED - CentOS 7.3SQL Ser ver: REDACTED 1REDACTED – Windows Server 201 2 R2Oracle DB: REDACTED 1REDACTED – CentOS 7 .3System S oftware in the Test Environmen ts
	184
	185	The follow ing table
	186	describes the base software e lements th at are req uired in t he test en vironment for this B uild Test Plan.
	187	Table 8: S oftware El ements
	188	Software E lement Nam eType and Other Note sTomcat 9. 0.0.M21Tom cat Server to host t he FPPS NE W web appl icationOra cle WebLog ic 12.2Web Logic serv er to host the FPPS NEW web ap plicationJ enkins Ser ver 2.71Je nkins serv er to run builds and automate the CI pro cessOracle Database 12cDatabas e for stor ing dataNo deJS 6.10. 3JavaScrip t runtime environmen t required to run FP PS NEWNPM 3.10.10Nod e Package Manager to install N odeJS depe ndencies r equired to run the F PPS NEW we b applicat ionJava(TM ) SE Runti me Environ ment (buil d 1.8.0_13 1-b11)Requ ired to ru n Jenkins CI, Tomcat and WebLo gicSQL*Plu s: Release 11.2.0.4. 0Command l ine interf ace to Ora cle Databa se used to manage da tabase sch emas, exec ute PL/SQL scripts a nd manage usersDepen dencies
	189	Office of Community Care (OCC) FTE resou rce may be required to answer specific t echnical q uestions r egarding O CC idiosyn crasies an d specific implement ation issu es.
	190	Access to existing O CC system codebases and enviro nment, spe cifically databases and or sch emas.
	191	Designated OCC repre sentative will revie w build te st documen tation for completen ess and ac curacy pri or to acce ptance.
	192	QA and UAT testing i s dependen t upon OCC QA resour ce availab ility.
	193	UNION Appr oval
	194	Notify Uni on Represe ntative(s) of any ch anges in w orking con ditions
	195	The Union Representa tive(s) to respond w ithin 14 d ays
	196	Dependency is IT QA completion which wil l generate the SOP n eeded to b egin UAT a nd union n otificatio n
	197	Union Repr esentative (s) will s end propos ed changes to Union members an d ask for feedback a nd/or acce ptance
	198	FTC will r espond to any union issues or concerns d uring the 14 days
	199	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
	200	Obtain Uni on accepta nce
	201	FTC expect s improvem ents to cu rrent prod uctivity a nd does no t anticipa te any neg ative impa cts to pro ductivity with minim al trainin g
	202	Other depe ndencies m ay be adde d pending Architect/ Tech Lead input.
	203	Risks and Constraint s
	204	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.
	205	Risk Descr iptionPote ntial Impa ct of Risk Realizati onStrategy - avoid, accept or mitigateIn tegrated e nvironment and/or co mponent, i ncluding t he associa ted networ k connecti vity, are unavailabl e.Would im pact the S QA Team’s ability to complete their sche duled test ing within the timef rame alloc ated.Mitig ate:
	206	Adjust tes t/work sch edules; wo rk with ex ternal gro ups to avo id outages If the ext ernal syst ems experi ence an ou tage, or p erform any un-planne d refreshe sThis will impact th e SQA sche duleMitiga te:
	207	Work close ly with ex ternal sys tems to en sure these refreshes or outage s are coor dinated wi thin the s cheduleReq uirements delivery l ate Risk to the sch edule due to late st art by dev elopmentMi tigate:
	208	Adjust tes t schedule ; Compress testing a ctivities; request s chedule va rianceStak eholder no n-complian ce (delays in sign-o ff)Risk to the final delivery date due t o delays i n Field Te st complet ion or app roval to r eleaseMiti gate:
	209	Maintain c lose conta ct with al l stakehol ders, keep ing them a pprised of deadlines Working wi th Integra ted teamsN ew system version ca n impact t esting and scheduleM itigate:
	210	Coordinate ; communic ate with i ntegrated teams and plan so th at schedul e will be impacted a s little a s possible .Potential issues du ring Deplo yment of B uild 3Risk to the sc hedule, po tential de lay in bui lds availa ble for te stingMitig ate or Acc ept
	211	Accept del ay
	212	Adjust tes t schedule ; Compress testing a ctivities; request s chedule va rianceTest Metrics
	213	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.
	214	Test metri cs may inc lude, but are not li mited to:
	215	Number of test cases (pass/fai l)
	216	Percentage of test c ases execu ted
	217	Number of requiremen ts and per centage te sted
	218	Percentage of test c ases resul ting in de fect detec tion
	219	Number of defects at tributed t o test cas e/test scr ipt creati on
	220	Percentage of defect s identifi ed; listed by cause and severi ty
	221	Acronyms
	222	COB
	223	Coordinati on of Bene fitsEDEEnt erprise De velopment Environmen tEWVEDI We b ViewerFP PSFee Paym ent Proces sing Syste mNPMNode(J S) Package ManagerOC COffice of Community CareOI&TO ffice of I nformation and Techn ologyPCSIP urchased C are System Integrity PWSPerform ance Work StatementS MESubject Matter Exp ertTRMTech nical Refe rence Mode lTRRTest R eadiness R eviewVIPVe teran Focu sed Integr ation Proc essAppendi x - Test T ype Defini tions
	224	Table 9: T est Type D efinitions
	225	Test TypeD efinitionD atabase/Ba ckend Test ingIn back end testi ng one is not requir ed to use the GUI; o ne can con nect to da tabase dir ectly and verify the data usin g SQL quer ies. Throu gh log fil es, debugg ing can be done.GUI/ Front-end TestingPro cess of en suring pro per functi onality of the graph ical user interface (GUI) for a given ap plication and making sure it c onforms to its writt en specifi cations. G UI testing evaluates design el ements suc h as layou t, colors, fonts, fo nt sizes, labels, te xt boxes, text forma tting, cap tions, but tons, list s, icons, links and content.Fu nctional T estingA ty pe of blac k-box test ing that b ases its t est cases on the spe cification s of the s oftware co mponent un der test. Functions are tested by feedin g them inp ut and exa mining the output, a nd interna l program structure is rarely considered (unlike w hite-box t esting). F unctional testing us ually desc ribes what the syste m does. Fu nctional t esting has many type s, includi ng, but no t limited to: unit, integratio n, smoke, regression , usabilit y, system, etc.Insta llation Te sting A ty pe of test ing that v erifies th at the app lication o r system i nstalls as intended on differe nt hardwar e and soft ware confi gurations, and under different condition s (e.g., a new insta llation, a n upgrade, and a com plete or c ustom inst allation). Installat ion testin g may also measure t he ease wi th which a n applicat ion or sys tem can be successfu lly instal led, typic ally measu red in ter ms of the average am ount of pe rson-hours required for a trai ned operat or or hard ware engin eer to per form the i nstallatio n. Part of this inst allation t est is to perform an uninstall . As a res ult of thi s uninstal l, the sys tem, appli cation and database should ret urn to the state pri or to the install. I ntegration Testing A n incremen tal series of tests of combina tions or s ubassembli es of sele cted compo nents in a n overall system. In tegration testing is increment al in a su ccessively larger an d more com plex combi nations of component s tested i n sequence , proceedi ng from th e unit lev el (0% int egration) to eventua lly the fu ll system test (100% integrati on). Load Testing A performan ce test th at subject s the syst em to vary ing worklo ads to mea sure and e valuate th e performa nce behavi ors and ab ilities of the syste m to conti nue to fun ction prop erly under these dif ferent wor kloads. Lo ad testing determine s and ensu res that t he system functions properly b eyond the expected m aximum wor kload. Add itionally, load test ing evalua tes the pe rformance characteri stics (e.g ., respons e times, t ransaction rates, an d other ti me-sensiti ve issues) . Performa nce Testin g Performa nce Testin g assesses how a sys tem is spe nding its time and c onsuming r esources. Performanc e testing optimizes a system b y measurin g how much time and resources the system is spendi ng in each function. These tes ts identif y performa nce limita tions in t he code an d specify which sect ions of th e code wou ld benefit most from optimizat ion work. Performanc e testing may be fur ther refin ed using s pecific ty pes of per formance t ests, such as, bench mark test, load test , stress t est, perfo rmance mon itoring te st, and co ntention t est. Regr ession Tes tingA type of testin g that val idates exi sting func tionality still perf orms as ex pected whe n new func tionality is introdu ced into t he system under test . Section 508 Compl iance Test ing A type of test t hat (1) en sures that persons w ith disabi lities hav e access t o and can interact w ith GUIs a nd (2) ver ifies that the appli cation or system mee ts the spe cified Sec tion 508 C ompliance standards. Security Testing A type of te st that va lidates th e security requireme nts and to ensure re adiness fo r the inde pendent te sting perf ormed by t he Securit y Assessme nt Team as used by t he Assessm ent and Au thorizatio n Process. System Te sting Syst em testing is the te sting of a ll parts o f an integ rated syst em, includ ing interf aces to ex ternal sys tems. Both functiona l and stru ctural typ es of test ing are pe rformed to verify th at the sys tem perfor mance, ope ration and functiona lity are s ound. End to end tes ting with all interf acing syst ems is the ultimate version. Unit/Produ ct Compone nt Testing Product C omponent T esting (ak a Unit Tes ting) is t he interna l technica l and func tional tes ting of a module/com ponent of code. Prod uct Compon ent Testin g verifies that the requiremen ts defined in the de tail desig n specific ation have been succ essfully a pplied to the module /component under tes t. User Fu nctional T estingUFT is a type of Accepta nce Test t hat involv es end-use rs testing the funct ionality o f the appl ication us ing test d ata in a c ontrolled test envir onment. C ommunity C are Electr onic Data Exchange ( CCEDI)
	226	13
	227	September 2017
	228	Build 3 Te st Plan