Qa Test Plan

8/12/2019 Qa Test Plan

1/17

Department or Program Name

[SYSTEM/APPLICATIONNAME]

Quality AssuranceTest Plan


2/17

SYSTEM/APPLICATION QUALITYASSURANCETESTPLAN

Project QA/Tet P!anTemplate Guidelines

To aid in the creation of a successfully completed Project QA/Test Plan, please review thefollowing guidelines. For additional instructions and information, please refer to theUniversity ervices Program !anagement "#ce. $emove these guidelines from the

completed document.

Purpose The Project QA/Test Planis an um%rella plan that encompasses the entiretesting re&uired for a project. 't is the highest level testing plan thatdocuments the testing strategy for the project, descri%es the generalapproach that will %e adopted in testing , provides the overall structure andphilosophy for any other re&uired testing documents, and de(nes what will%e tested to assure the re&uirements of the product, service, or system )i.e.,the delivera%les* are met.+ased on the sie, comple-ity, and type of project, subsequent test plansmay %e created and used during the testing process to verify that thedelivera%le wors correctly, is understanda%le, and is connected logically.

These test plans include the following categories and types. Testingareas/coordinators would have templates speci(c to these plans.

Types of quality assurance planninginclude Process QAplans document how the project is meeting &uality and

compliance standards ensuring the right documentation e-ists to guideproject delivery and corrective actions, and

Requirements/application test plansdocument how the product,service or system meets stated %usiness and technical re&uirements,and how it will wor within the de(ned operational/%usiness processesand wor 0ow.

Test plans typically used for development eortsinclude

Unit Test Plans UT* documents what the programmer is coding for aparticular screen or unit.

!ntegrated "ystems Test Plan)!"T* documents how the system will%e tested to assure major errors are (-ed and how end1to1end testing%etween one1o2 applications will occur.

!ntegration Application Test Plans !AT* documents howapplications will test end1to1end all new functionality across allapplications.

User Acceptance Testing)UAT* documents how the users, who will%e supporting the new and e-isting functionality in production, will testthis new functionality prior to production installation.

#perations !nterface Readiness Test Plan)#!R* documents howthe operations user will test all new and e-isting functionality.

Testing approaches that may %e used to test or validate projects that havehigh ris or impact include Regression Testingensures all (-es identi(ed during 'AT and UAT

were made to the system and did not impair ey e-isting functionality(used mainly with new major software development projects).

$onversion !ntegration Application Testingis used to simulate the(rst couple of processing days following a conversion.

Prototypeis a techni&ue used either in the design, %uild, or testing


3/17


stage to construct a model of the product, service, or system to verify afunction, a design, how a particular module or program wors, etc.

Proof of $onceptis used to test an idea in a controlled environmentto test new features.

Alpha Testingtests a new product, service, or system %eforeimplementation where it may have major impacts and the project team

wants to identify major pro%lems/%ugs %efore implementation )or goesinto production*.

%eta Testingdi2ers from Alpha Testing in the amount of testing andclean1up that needs to %e performed. The project should %e ready forimplementation.

Pilotis a limited use of the product, service, or system %y a remotesite, su%set of the customer %ase, etc. This testing techni&ue is used towor out logistical pro%lems, validate the delivera%le, and minimieimpact %y limited rollout.

Parallel Testingoccurs when the old and the new product, service, orsystem are running simultaneously to allow the project customer tochec that the delivera%le is woring per speci(cations.

"tress/&oad Testingensures the system will perform relia%ly during

full production and heavy worloads. #perational/%usiness Readiness Testingwals through the

operational/%usiness processes and wor0ows to ensure thatprocedures, documentation, reconciliation, training, and wor 0ows arecomplete and correct.

#'nership The Project !anager is responsi%le for ensuring that all testing plans arecreated and identi(es them under one um%rella plan )i.e., the !asterProject QA/Test Plan*. The project testing team lead)s* develop thenecessary su%se&uent test plans.

(henPhase3esigntagePlanning

The Project QA/Test Plan is completed during the 3esign phase of theolution 3elivery 4ife 5ycle. 't should %e updated anytime additionalinformation or project changes a2ect its content.

't is a re&uired delivera%le on 4arge and !edium projects, and a %estpractice on Fast Trac projects. For additional guidance, the Project5lassi(cation 6orsheet is availa%le.


4/17


Template$ompletion7ote Te-twithin ) *%racets needto %e replaced

with project1speci(cinformation.

8. 3o not include the Template 9uidelines in your (nal document. :nterthe project information in the page header and footer, title page, anddocument contri%utors and version control.

;. 5omplete the document utiliing suggested te-t where applica%le andentering te-t/(elds where shown within


5/17


DOCUMENTIN"ORMATIONANDAPPRO#ALS

.+R"!#-!"T#R0

#er$on % Date Re&$e' () Reaon *or c+ange

,-. /01/,0 Aaron Demenge PMO Re&$e2

1#$U2+-TAPPR#.A&"

Appro&er Name Project Ro!e S$gnat3re/E!ectron$c Appro&a! Date


6/17


TA(LEO"CONTENTS

Intro'3ct$on----------------------------------------------------------------------------------------------------------------------,

Scope...................................................................................................................................................... 1

Test Objectives........................................................................................................................................ 1

Testing Goals........................................................................................................................................... 1

Tet Met+o'o!og)------------------------------------------------------------------------------------------------------------0

Entrance Criteria..................................................................................................................................... 2

Exit Criteria.............................................................................................................................................. 2

Test Execution......................................................................................................................................... 2

Test Scenarios.........................................................................................................................................3

Test Case/Script evelopment................................................................................................................ !

e"ect #eporting.................................................................................................................................. ... !

Tet En&$ronment-------------------------------------------------------------------------------------------------------------4

So"t$are #e%uirements...........................................................................................................................&

'ard$are #e%uirements..........................................................................................................................&

Testing (lat"orm....................................................................................................................................... &

Uer Acceptance Tet P!an---------------------------------------------------------------------------------------------4

e"inition................................................................................................................................................. &

Testing #e%uirements..............................................................................................................................)

Testers/(articipants................................................................................................................................. )

Testing Sc*edule..................................................................................................................................... )

A3mpt$on an' R$5--------------------------------------------------------------------------------------------------1

+ssumptions............................................................................................................................................ ,

#is-s..................................................................................................................................................... .. ,

6o/No7go Meet$ng------------------------------------------------------------------------------------------------------------1

A''$t$ona! Project Doc3ment---------------------------------------------------------------------------------------8

Ro!e an' Repon$9$!$t$e---------------------------------------------------------------------------------------------8

S$gn7o** an' Ac5no2!e'gement-------------------------------------------------------------------------------------:

Tet D$rector ; De*ect Trac5$ng Proce---------------------------------------------------------------------,,


7/17


8/17


9/17


Unit testing has %een completed %y the development team, including vendors. All hardware needed for the test environment is availa%le.

The application delivered to the test environment is of relia%le &uality.

'nitial smoe test of the delivered functionality is approved %y the testingteam.

5ode changes made to the test site will go through a change control process.

E?$t Cr$ter$a

All test scenarios have %een completed successfully. All issues prioritied and priority 8 issues resolved.

All outstanding defects are documented in a test summary with a priority andseverity status.

9o/7o1go meeting is held to determine accepta%ility of product.

Tet E?ec3t$on

The test e-ecution phase is the process of running test cases against the software %uild toverify that the actual results meet the e-pected results. 3efects discovered during the

testing cycle shall %e entered into the project harePoint Team ite 3efect list or Quality5enter )o2ered %y "'T*. "nce a defect is (-ed %y a developer, the (-ed code shall %eincorporated into the application and regression tested.

These following testing phases shall %e completed )if applica%le*

Unit Testing

Unit testing is performed %y the report developers at U ervices 'T and "'T in theirdevelopment environment. The developers now and will %e testing the internal logicalstructure of each software component. A description of the unit testing should %e providedto the project team.

Functional Testing

Functional testing focuses on the functional re&uirements of the software and is performedto con(rm that the application operates accurately according to the documentedspeci(cations and re&uirements, and to ensure that interfaces to e-ternal systems areproperly woring.

Regression Testing

$egression testing shall %e performed to verify that previously tested features and functionsdo not have any new defects introduced, while correcting other pro%lems or adding andmodifying other features.

Integration Testing

'ntegration testing is the phase of software testing in which individual software modules are

com%ined and tested as a group. 'n its simplest form, two units that have already %eentested are com%ined into a component and the interface %etween them is tested. 'n arealistic scenario, many units are com%ined into components, which are in turn aggregatedinto even larger parts of the program. The idea is to test com%inations of pieces andeventually e-pand the process to test your modules with those of other groups. :ventuallyall the modules maing up a process are tested together.

212 #egents o" t*e 0niversit o" innesota. +ll rig*ts reserved. #evised ul 1!4 21! (age 3


10/17


Interface Testing

This testing follows a transaction through all of the product processes that interact with itand tests the product in its entirety. 'nterface testing shall %e performed to ensure that theproduct actually wors in the way a typical user would interact with it.

Destructive Testing

3estructive testing focuses on the error detection and error prevention areas of the product.This testing is e-ercised in an attempt to anticipate conditions where a user may encountererrors. 3estructive testing is less structured than other testing phases and is determined %yindividual testers.

User acceptance testing

User acceptance testing activities will %e performed %y the %usiness users. The purpose ofthis testing will %e to ensure the application meets the users? e-pectations. This alsoincludes focuses on usa%ility and will includeJ appearance, consistency of controls,consistency of (eld naming, accuracy of drop down (eld information lists, spelling of all (eldname/data values, accuracy of default (eld values, ta% se&uence, and error/help messaging

Tet Scenar$o

+elow are the high1level scenarios that will %e tested. These scenarios are derived from the$e&uirements !atri- and Use 5ases. From these, detailed test scripts will %e created.

!13

-umber

Test "cenario 1escription

Test"cript

Reference

Testing

$omplete4

A&& "TAT+1 R+QU!R+2+-T" +5!"T A-1 6U-$T!#-

@@8

BA test scenario is almost lie a story Ka user enters into theapplication from login window %y entering valid user name andpassword. After entering he will clic on module Payslip and clicson latest payslip feature to view his latest payslipK. Any testscenario will contain a speci(c goal.C

@@;"+$UR!T0

@@> BAdd description of re&uirements.C@@1ATA .A&!1AT!#-

@@L BAdd description of re&uirements.C@@M

+-.!R#-2+-T@@N BAdd description of re&uirements.C@@O!-T+R6A$+"

@@ BAdd description of re&uirements.C@8@

212 #egents o" t*e 0niversit o" innesota. +ll rig*ts reserved. #evised ul 1!4 21! (age !


11/17


Tet Scr$pt De&e!opment

Test script design is the central focus of a software &uality assurance process. A test script isde(ned as a written speci(cation descri%ing how a single or group of %usiness or systemre&uirement)s* will %e tested. The test script consists of a set of actions to %e performed,data to %e used, and the e-pected results of the test. The actual results of the test arerecorded during test e-ecution. Test scripts will also %e updated as testing proceeds.

Test cripts written for this project include the following Test cript '3 Test 5ases veri(ed

$e&uirements veri(ed Purpose of test Any dependencies and/or special set1up instructions re&uired for performing

the test Test description and steps

:-pected results

De*ect Report$ng

'ssues/defects are traced for resolution with the following guidelines 'ssues will %e reported %ased upon documented re&uirements.

'ssues will %e traced %y the testing team, reported and entered into Quality5enter.

'ssues will %e (-ed %y the development team %ased on the priority/severityassigned %y the test lead.

All critical/priority 8 defects will %e (-ed %efore release to production.

ee the 3efect Tracing Process at the end of this document for detailed instructions on howto log and trac defects in Quality 5enter.

TESTEN#IRONMENT

Re=3$rement

5lient erver Technical $e&uirements !i-ed %rowsers supported )'nternet :-plorer, Firefo-, !oilla* "racle 3ata%ase 5lient Platform P5 and !acintosh

Production server location

Testing Platform

3estop P5 the application supports all A19rade %rowsers for 6indows and!ac operating systems , as de(ned %y ahooR?s 9raded +rowser upport standards.http//developer.yahoo.com/yui/articles/g%s/ 6indows ;@@@/':M may %e e-cluded.

Test server location

USERACCEPTANCETESTPLAN

De*$n$t$on

The overall purpose of testing is to ensure the Bname of applicationC application performs atan accepta%le level for the customer. This section outlines the detailed plan for useracceptance testing of this application.

212 #egents o" t*e 0niversit o" innesota. +ll rig*ts reserved. #evised ul 1!4 21! (age &


12/17


This test plan will %e used to record the customer?s sign o2 of the documented scenarios.3etailed test scripts/cases have %een developed and will %e used to record the results ofuser testing. This document is a high level guide, and is not intended as a replacement forany speci(c user acceptance testing procedures that individual areas might have.

Tet$ng Re=3$rement

Testing will tae place in Binsert locationC. ome testers may choose toperform some testing from their regular worstations where it is possi%le. Test resultsmust still %e coordinated with others.

UAT will tae place %eginning on Binsert dateC.

'denti(ed testing participants will receive instructions prior to the start oftesting.

'denti(ed testing participants will perform the e&uivalent of their normal%usiness function in the upgraded environment.

Test scripts/cases and scenarios will %e prepared prior to the start of UAT.

Test participants will conduct the tests and document results. 3efects will %e entered into Test 3irector and traced %y the Test 4ead.

Teter/Part$c$pantTesting participants should include representatives from all areas involved in the application.There are %ene(ts to including representatives from across all areas to validate the systemsfunctions %efore the upgrade goes live in production.

The %est candidates for UAT are ta2 directly impacted %y the upcoming system and %usiness process

changes. Fre&uent users of the application and functions planned in test scripts/cases.

'ndividuals with a sound understanding of %usiness processes in the areasthey represent.

'ndividuals with the necessary time to commit to this endeavor.

6illing to e-periment )to try various methods to see what wors and what

doesn?t wor*. Patient and have a tolerance for am%iguity.

Teter Name Department/Area Repreent$ng Area o* Tet$ng "oc3

Tet$ng Sc+e'3!e

All upgraded functionality and test data will %e migrated to the test environment prior to thestart of user acceptance testing.

Act$&$t) Lea' Repon$9$!$t) Date

'dentify and select testers for UAT3evelop test scenarios and scripts/casesDalidate participants availa%ility for testing$eview scenarios/scripts for accuracy,completeness and se&uence )con(rm testdata is correct*

212 #egents o" t*e 0niversit o" innesota. +ll rig*ts reserved. #evised ul 1!4 21! (age )


13/17


:nsure UAT 4a% destops con(gured fortestingUAT environment validation

Testing %y UAT participants

ASSUMPTIONSANDRIS@S

A3mpt$on

The +usiness team has reviewed and accepted functionality identi(ed in the%usiness re&uirements and software re&uirements documents.

Project change control process in place to manage re&uirements.

5ode walthroughs/reviews will %e completed %y the development team.

Unit testing will %e completed %y the development team prior to release to thetest team.

Testers will test what is documented in the re&uirements. The test team will have a separate test environment to perform testing.

All changes to re&uirements will %e communicated to the test team.

$esources identi(ed in this plan are availa%le to test the application and

resolve defects and address issues as they are raised %y the test team. That the delivery of the product to production contains all setup, etc., that is

necessary for optimum performance in the production site. Project sponsors, %usiness and technical, will provide actiona%le guidance on

defect prioritiation and resolution. The UAT environment will %e availa%le and destops will %e availa%le to

perform testing.

R$5

cope creep )last minute addition of new re&uirements* impacts deadlines fordevelopment team and test team.

Aggressive target date increases the ris of defects %eing migrated to

production. 'f development timelines are not met, this will directly impact the testingtimelines.

Sey resources have completing priorities maing availa%ility less thanscheduled.

Any downtime of the test system will signi(cantly impact the testing cycle. 4oad testing is not %eing completed on a consistent %asisJ true performance of

the application may not %e nown until release to production.

6O/NO76OMEETIN6

"nce the test team has completed the test cycle, a 9o/ 7o1go meeting is scheduled as partof the implementation planning under launch readiness. This meeting is attended %y the

project manager, %usiness team, test lead, technical lead, and any other staeholders.

The test lead will provide a testing summary and list all outstanding unresolved defects andany associated riss with releasing the product to production. All outstanding issues arediscussed at that time %efore a decision is made to push to production. A written sign1o2form is signed %y all team mem%ers as listed a%ove. The list of outstanding issues is alsoattached to the sign1o2 form.

212 #egents o" t*e 0niversit o" innesota. +ll rig*ts reserved. #evised ul 1!4 21! (age ,


14/17


ROLESANDRESPONSI(ILITIES

Reo3rce T)pe Repon$9$!$t$e Name

"ponsor Provides 9o/7o 9oauthoriation that product is ready forrelease as part of implementationplanning and launch process

Priorities issues and defects,and manage technical resources

!aes decisions onunresolved issues

Project 2anager Provides guidance on theoverall project

5oordinates and developsproject schedule

4iaison with %usiness toensure participation and ownership

Tracs all project activities

and resources, ensuring project remainswithin scope Facilitates identifying and

%ringing closure to open issues 5ommunicates project status

"ubject 2atter+7perts

3e(ne %usiness re&uirementsand e-pected results for %usinessacceptance

:-ecute user acceptancetesting

1ev Team &ead 3esign applicationarchitecture

5reate technical design

3ata%ase Administrator1evelopers 6rite application code

$esolve defects

upport testers

%usiness &ead 6rite %usiness re&uirements,test plan and test cases

!aintain re&uirements anddefect reporting in Test 3irector

4ead testing cycle

QA &ead !aintain project in Test3irector

6rite test plan to include test

scenarios and cases Facilitate testing !aintain and manage defects

in Test 3irector%usinessAnalyst

6rite %usiness re&uirementsand %uild test scripts

!aintain re&uirements in Test3irector

4ead testing cycle and



15/17


coordinate test environmentTesters Perform user acceptance

testing

SI6N7O""ANDAC@NOLED6EMENT

' understand that %y agreeing to participate in this testing through the e-ecution of thetesting plan, ' approve of the activities de(ned and authorie my department to participateas documented for the successful implementation of this application in our department.

3ate //$esource 7ame

Title or $esponsi%ility













3ate //$esource 7ameTitle or $esponsi%ility



16/17


TESTDIRECTOR; DE"ECTTRAC@IN6PROCESS

S3mmar)BScreen name and s*ort description about t*e de"ect being reported4 usuallproviding -e $ords $it* $*ic* to identi" and/or searc* "or t*e de"ect.

Detecte' ()B +uto populates $it* t*e 0ser 7 o" person logged in.

Detecte' on DateB +uto populates $it* current date.

Se&er$t)Bescribes t*e degree o" impact t*at a de"ect *as on t*e operation o" t*eapplication.

A$gne' ToB 7ndividual being assigned t*e de"ect "or "ixing.

Detecte' $n (3$!'B8uild 7 in $*ic* t*e de"ect $as "ound. 8uild 7 is an identi"ier "or t*e coderelease4 assigned b 9eb evelopment.

"$?e' $n (3$!'B8uild 7 in $*ic* t*e de"ect is "ixed. 8uild 7 is an identi"ier "or t*e coderelease4 assigned b 9eb evelopment.

Pr$or$t)BT*is "ield describes t*e impact t*e de"ect *as on t*e $or- in progress and t*eimportance and order in $*ic* a bug s*ould be "ixed.

Stat3B 7ndicates t*e existing state o" a de"ect4 auto populates $it* a de"ault o" :;e$

Qa Test Plan

Documents

Transcript of Qa Test Plan