Test Plan Template - Save for Future Use on a Project

7/28/2019 Test Plan Template - Save for Future Use on a Project

1/21

Test Plan Template Information/DirectionsDirection: This page is for the preparers information. It should be printed forreference and deleted.

Instructions: Instructions are italicized, in red, and surrounded by a paragraph border (like this

paragraph). Delete instructions once initial preparation of the document is complete.

Color scheme for template:

Red = Instructions (delete when test plan is complete)Blue=Examples; replace with correct information and change font to black

Drafts: During initial plan preparation, the word Draft should appear on all copies. Once the plan is

ready for approval, delete Draft from the cover page and from the footer.

Plan Modifications: Update the document date on the cover page and in the footer each time the plan

is modified. When modifications begin for a new version (after an approved release), update the versionidentifier on the cover page and in the footer for major/approved (R number) release and minor/draft

(C number) revisions. Reinsert the word Draft in the footer and on the title page.

Headings: To add a heading: type the heading; then click the Styles drop box and click the appropriate

level head, for example:Part Heading 1I Heading 2I.A Heading 3I.A.1 Heading 4Use Heading 3 for Appendices.

If a section does not apply, enter This section is not applicable and explain why it is notapplicable.

Other/additional local policies for approval of variances from this standard must also befollowed.

Updating Footers: The footer of the plan needs to be updated in the following manner:

- In the first line, insert the word Draft.- In the second line, insert the template date with last modified date in the format MM/DD/YYYY (e.g.,

02/01/2003). Do not use the Print Date field/function.

Generating Tables of Contents, Figures, and Tables: To update a generated list (table of contents,

list of figures, list of tables) do the following: (1) right-click inside the gray shaded area, (2) click UpdateFields, and (3) click Update Entire Table.

Figures and Tables: Figures and tables should be numbered sequentially beginning with Figure 1 or

Table 1. If you add a figure or a table, update the figure and table numbers globally if appropriate. If onlyone figure or table is in the document, do not number it.


2/21

Test Plan

Client Logo goes here

DRAFT

Functional Test Plan

This document describes the plan for preparing and executing Testing for theproject.

Revision

Page 2 of 21 v3.0.1 Revision Date 4/8/2013

Client Logo goes here


3/21

Test Plan

Table of Contents

Part 1 Test Management.........................................................................................................................5

.I Project Overview...................................................................................................................................... 5

.II Test Scope............................................................................................................................................ . 5

.A In Scope.............................................................................................................................. ...... 5

.B Out of Scope.............................................................................................................................. 6

.C Reference Documentation.........................................................................................................6

.D Testing Schedule.......................................................................................................................6

.E Testing Environment..................................................................................................................6

.F Data Management..................................................................................................................... 7.III Test Methodology.................................................................................................................................. 7

.A Test Activities.................................................................................................................... ........ 7

.B Test Case / Script Development............................................................................................. 11

.C Test Tools................................................................................................................................11.IV Test Management............................................................................................................................... 12

.A Personnel................................................................................................................................ 12

.B Assumptions and Risks....................................................................................................... .... 13

.C Communication....................................................................................................................... 15.D Change Management.............................................................................................................. 15

.E Success Measurements..................................................................................................... ..... 16.V Defect Management............................................................................................................................. 16

.A DefectTracking/Reporting Process..........................................................................................16

.B Assigning Priority vs. Severity Levels...................................................................................... 18

.C Reporting Defects....................................................................................................................19

Appendices............................................................................................................................................ .. 21

.A Test Case / Script Template.................................................................................................... 21

.B Project Test Methodology Acronyms List.................................................................................21



4/21

Test Plan

Revision History

No. Date Version No. By Reason

Approval

This list should include project leadership from both Company X and Client side. Since the Test Planimplies contractual obligations regarding test activities, the approvers below should be senior enough torepresent agreement by the areas they represent.

The list below is provided as an example.

Organization Role Name Phone # Cell/ Pager # Approval?

Project Manager

Business Analysts

QA Manager

DevelopmentLead or Manager



5/21

Test Plan

Part 1 Test Management

.I Project Overview

This paragraph should briefly state the purpose of the system / software under test and describe theobjective of the testing project.

A key component of this section is the intent to conform to standards.

Company Xs high level Testing Objective for the project is to systematically and thoroughlyverify that all Software, Sub-Systems, and Associated Processes being Developed, Modified, and orIntegrated by Company X and or external parties represented by Company X, are in compliance to thestated requirements of the project BRD/TDD documentation, to include implicit requirementscritical to the operational success of the project.

All testing activity associated with this project will conform to the standards and expectations of the

Company X Global Test Management Testing Methodology as to provide valid, thorough, traceable, andverifiable results. This document will address each type of testing that is to be employed by Company X inorder to meet the above stated Testing Objective.

.II Test Scope

This paragraph should clearly list out what exactly is going to be covered in the testing and what will notbe covered during the testing.

.A In ScopeCan also provide link to an Application Footprint or similar document.

Remember to consider whether ADA Compliance testing is In Scope or not.

This test plan covers the implementation of the software and related components to supportthe for . The following applications and components are included:

Name Description

All phases of testing identified in this document as within scope will include at a minimum, allnewly customized or configured functionality including screens and reports as applicable.



6/21

Test Plan

.B Out of ScopeInsert testing work effort that will be out of scope for this testing effort. Make sure your PM, IT ServiceDelivery Mgr, or equivalent leadership role approves the Out of Scope items in particular, as part ofoverall Plan approval.

Typical items to include here would be later phase work, defect resolution, certain test execution (such as

Unit Testing), desktop or server configuration, architectureand anything specific to your work effortwhich clearly needs to be documented as outside the scope of this Test Plan.

The following table outlines work that is out of scope for testing during this project. Some of these itemsmay be considered for future releases. The table list initiatives that are either completely out of scope orare potential components for long-term/future releases.

Timing Work components

Out of Scope

.C Reference Documentation

This section should list the number, title, version numbers, and date of all documents referenced in thistest plan

.1 BRD/slist BRD name(s) and revision(s) here

.2 TDD/slist TDD name(s) and revision(s) here

.3 Project Planslist Project Plan (not schedule) name and revision here

.D Testing Schedule

.E Testing Environment

Identify the specific hosting environment where the testing will be conducted.

System Integration Testing will occur in the QA environments and on Company X supportingsystems and interfaces as necessary.



7/21

Test Plan

.F Data Management

This section describes

What data is required for data entry and for being acted upon by the tests

When it will be obtained

From where it will be obtained

Where it will be stored

How it will be managed before, during, and after testing

.III Test MethodologyThis section gives an overview of the general process to be followed to accomplish testing.

.A Test ActivitiesThis section describes how the testing process will be organized into testing activities. The staging,

phasing, or other organization of the test activities will be project dependent, and will dictate the

organization of the Test Designs in Part 2.

As an example, this section provides a high level description of the testing phases employed by CompanyX Global Test Management. Other organization schemes could be by Application, by business Domain,by Release, by Client organization, etc.

This section explains the execution of three testing phases planned by Company X.

Unit Testing Phase (conducted as part of Development team tests)

System Integration Testing (SIT) Phase

User Acceptance Testing (UAT) Phase (conducted jointly by /Company X team)

In addition, Production Staging entry and exit criteria are provided.

.1 Unit Testing (UT)

.a Definition



8/21

Test Plan

Unit Testing is the formal testing of source code by the developer who wrote it. The word unitcan refer to a sub-routine, a module, an object or class, or an even larger programming entity. Itshould be required for each unit before that unit is integrated with the master sources or turnedover for independent review or testing. It is at this stage where all online transactions, inquiries,reports, and application engine processes within a specific module are tested. The testinginvolves identifying or ensuring the sufficiently detailed conditions which test all the processingeventualities, setting up test data to test each of the conditions, planning the expected results andthen testing that each condition is met, or fixing and retesting until all conditions are met.Documentation of the test should be kept for reference..bUnit Testing includes testing of all application development, Graphical Unit Interface (GUI), andindividual system interface development prior to SIT and UAT. Unit Testing is performedinternally and does not require s involvement and sign off. Unit Testing will be theresponsibility of Company X and developers as applicable per their development responsibility. Inaddition, unit testing of the interfaces will be the responsibility of Company X and developers asapplicable per their development responsibility. The Company X Testing team will reviewdevelopers test results as part of the System Integration Test (SIT) preparation and execution..c

.2 System Integration Testing (SIT)

.a Definition

System Integration Testing (SIT) includes verification of system integrity, data, transaction flows,connectivity and delivery of integrated business functionality across all applications, functions andinterfaces. It will exercise the end-to-end data flow. The primary focus for SIT will be interfacetesting and application functionality verification. SIT does not require team membersinvolvement or approval, although some members of the business project team may be availableto participate in the SIT functionality testing in the SIT environment on a limited basis and asnecessary to ensure the success of the project. SIT will include verification that all changed orimpacted interfaces have basic connectivity (files can be sent and/or received without abnormalinterruption of executables), significant rejects, or loss of data) and have the continued ability toprocess without errors that will interrupt processing during Systems Integration Testing (SIT)phase.

.b Approach

The following is the Company X approach to accomplishing System Integration Testing:

Breakout the testing into cycles so as to most effectively integrate portions of the application.

Verify that the data or commands passed from one component are correct and operate

effectively with other related components.

Successfully test the creation and passing of the internal interface files and verify that no

defects or issues remain in the vendor processing of interface files.

Verify that batch (technical) processes work from end-to-end across all components.

In addition, SIT includes the following activities:

Error Testing:

This will be included within the SIT testing phase. This will be documented in the SIT test cases.Error testing is defined as negative testing of interfaces and functional processes. This shouldinclude loss of connectivity to interface testing/error validation.

Data Integrity Testing



9/21

Test Plan

Regression Testing

.a SIT (System Integration Testing) Entrance Criteria

The following criteria must be met before Integration Testing can begin. If any of the following

criteria are not met, risk is introduced with regards to the successful completion of SIT.

Completion of Unit Testing

All Business Requirements Documents (BRDs) are completed and provided to the Test

Team.

All Technical Design Documents (TDDs) are completed, approved and provided to the Test

Team (including myHR, compensation, reporting, interfaces, etc).

All associated applications installed and accessible in a stable technical environment.

Systems Integration Test Planning is completed.

SIT test resources identified and available for testing.

Appropriate accesses received to appropriate applications and environments

Migration Plan for the movement of Code from Dev to Testing environment.

Test cases prepared and signed off for each test case to be executed. Data requirements are identified.. SIT cases are detailed with test data for each testing

condition or step defined in the test case matrix.

.b SIT (System Integration Testing) Exit Criteria

The following criteria must be met before SIT can be considered complete. If any of the followingcriteria are not met, risk is introduced with regards to the successful completion of SIT.

Successful execution of all cases with actual results documented.

No open Severity 1 or 2 Incidents.

Target dates for closure of Severity 3 and 4 Incidents identified. (Please see the below

Incident Code Definition Table) Any specific requirements for SIT exit and UAT entrance established by the Business Teams

are satisfied.

Issue logs are updated, filed and available for review.

.3 User Acceptance Testing (UAT)

.a Definition

User Acceptance Testing (UAT) provides the opportunity for users from Company X and to exercise the system in a simulated production environment and thereby certify that thedelivered functionality processes data correctly and that the delivered functionality conforms tothe agreed upon requirements.

.b Approach

Company X Test Management will work with the Company X and UAT Test leads tocoordinate and conduct the UAT Testing activity. The scope of the testing effort from the UATtesting perspective is determined by Company X and but the Test Management teamwill support/assist in preparing a test plan and test cases based on defined production businessprocesses. In addition Test Management will work with Company X and to determinetest environment requirements (interconnectivity, ID setup, etc).



10/21

Test Plan

UAT will include validation of specific user functionality as determined by Company X and. Company X and will develop UAT Test Cases with the assistance of CompanyXs Test Management team, based upon defined production business processes. Furthermore,Company X has been charged with the overall management of UAT to include assistingCompany X and to develop test cases, distribution of the same, coordination ofenvironment preparation (including data loads and ID setup), Test Execution planning andmanagement, and the scheduling and leading of regular daily execution status meetings throughUAT exit and signoff.

.c UAT Entrance Criteria

System Integration Testing has been successfully completed by Test Management (exit

criteria has been met).

Signoff on SIT results obtained

Signoff on UAT Test Plan obtained.

UAT cases have been written, reviewed and approved.

UAT test resources identified and available for testing.

All objects have been successfully migrated to the UAT environment.

The UAT environment has been verified prior to user execution, required data exists, and

tester IDs have been configured. User access to the environment has been validated.

If required, security testing has been completed and sign off attained from the security group.

.d UAT Exit Criteria

The functionality and business requirements are satisfied.

No open Severity 1 or 2 Incidents.

Target dates for closure of Severity 3 and 4 Incidents identified..(Please see the below

Incident Code Definition Table)

All code changes have been migrated and retested.

All critical defects have been resolved.

Issue logs are updated, filed and available for review. Business processes, scenarios, and configurations have been validated.

Successful execution of all cases with actual results documented.

A plan is in place to address any deferred defects.

Signoff from (through the UAT Test lead) that UAT has met the exit criteria



11/21

Test Plan

.B Test Case / Script Development

Developing Test Cases

A test case or scenario is a description of what will be tested; the situations and processeswhich should be included in test coverage. Test cases are based upon, and must be traceableto, business requirements or technical/functional specifications.

Since exhaustive testing is prohibitively costly, prioritization must be used to test the mostimportant situations. For this reason, test cases and scenarios will be developed to

Represent significant events

Represent events most likely to occur

Represent events that account for the most activity

Included in this test suite will be cases which test system boundaries by defining test conditionsthat will result in both negative and positive results. For instance, in order to test error messagesand Help text, invalid data should be entered.

Test case developers must ensure that appropriate test cases are developed for everypanel/page, on-line process and batch process to be used in production.

.a Organization of Test Cases

Describe how and where Test Cases will be organized and managed.

The scope of what will be executed during all Test cycles is completely defined by the Test CaseMatrix developed for each Test Activity. The Company X Test team members will develop theBusiness Event/Component Test Case Matrix with support from the Business Analyst/SMEs andDevelopers who are knowledgeable about the technical requirements of the project.

(* See Test Execution Metrics and Work Plan embedded in this document Appendix A)

.C Test ToolsDescribe in this section the general (i.e. not phase or test-specific) testing tools which will be used,e.g. Maestro, Test Director, etc. If there are multiple tools being used for different parts of the project,describe how tool usage will be coordinated. Remember to account for any tool training needs in theTest Management Personnel section below.

Phase or test-specific tools (e.g. Performance testing tools, Keystroke recorders for UAT, etc.) wouldbe described in the specific Test Design for that phase or test.



12/21

Test Plan

.IV Test Management

This Test Plan and associated Test Cases define the steps and components that will be tested and arethe baseline against which the progress will be measured. The following procedures provide a frameworkfor how the test effort will be organized and managed.

.A Personnel.1 Roles & Responsibilities

Once the affected or involved organizations have been documented, describe who in those organizationsis responsible for what deliverables and activities.

Organization Role Name Key AccountabilitiesCompany X FlexStaffing

Client AccountManager

Company XDeliveryManagement

ProjectManager

Support day to day interface with the client.

Provide high level oversight regarding the

overall project.

Company XDeliveryManagement

TechnicalLead

Support resolving incidents, developing the

code fix for the identified incident, moving thenew code into the test environment for SIT andUAT testing code migration needs to befurther defined.

Development and execution of the on-line

process testing and assisting with the batchprocess testing during System IntegrationTesting.

Assist with on-line and batch processes

Manage the resolution of technical issues

encountered throughout the testing cycles

Company X TestMgt.

TestCoordinator

Oversee and coordinate all aspects of the

testing processes, specifically:

Document Test Strategy & Approach Coordinating Test Script Creation

Daily Test Status Reporting

Test Incidents (managing and tracking)

Test Support tools

Quality Assurance Oversight

Facilitating testing status meetings

Coordination of testing phases and dates for SIT

and UAT

Support and Manage Test Execution

Identify, resolve, and escalate test incidents and

issues

Coordinate with the software vendor(s) andtechnical teams

Coordinate with the business team

Monitor and report status of Script Execution

Facilitate testing/incident meetings

Coordinate with the development team to

resolve incidents

Coordinate the development of all test forms,

templates and information flows



13/21

Test Plan

Organization Role Name Key Accountabilities Provide necessary training to the Test Team

with the assistance of Business Analysts

Track all test cases with dependency

relationships to ensure that they are scheduledand completed in the appropriate cycle

Review test results and ensure that they areproperly documented

Company X TestMgt.

Test Analysts /Testers

Off ShoreTeam

Develop test cases based on business

requirements

Develop Business Events

Develop and execute test cases for SIT

Review test cases for UAT

Support script scheduling and integration

coordination

Identify and retest incidents

Identify business events/components and

test cases which must be tested

Assist in the development and reviews ofprocess test cases; expand these cases duringtesting as necessary

Execute the test cases and validate the

results

Assists in the execution of the batch

processes for testing purposes when applicable

Review and validate all of the test results

from the batch process testing

Document actual test results in the Test

Case Matrices and Cases

Document test case failures and report to

System Integration Test Lead

Assist in resolving problems that may

surface during testingAnswer questions that may arise during testing

etc

.B Assumptions and Risks

.1 Assumptions

List the dependencies or events outside of the testing process upon which successful testing relies.Document a contact who has confirmed that the assumed activity or event will take place.

Assumption

Type

(Process, Resource,or System)

Confirmedby:

Prior to SIT, the development team will have successfullycompleted Unit Testing and met the exit criteria.

System

A verified, stable, and accessible testing environment will beavailable for SIT in accordance with the approved project planand schedule.

System

The Company X SIT test team will conduct functionality testing. Resource, System



14/21

Test Plan

AssumptionType

(Process, Resource,or System)

Confirmedby:

All testing is at high risk if Business Requirements Documents,Technical Design Documents have not been created, peerreviewed, approved and presented to Test Management

before the SIT phase begins.

Process

(Project Management)

During SIT, the test environment and application code will receiveNO modifications of any kind without the concurrence of theCompany X Project Test Coordinator or designee.

Resource

Releases of the application to test will be fully complete as torepresent a complete production system capable of meetingthe needs of the associated testing.

Resource

SIT test cases will pass all business reviews and approvals per thedefined process within the established test plan timeline.

Process

The Company X infrastructure team will perform system stresstesting.

System

A PeopleSoft and CDS environment will be available to testinterfaces.

System

etc

.2 Risk Assessment

List the dependencies or events within the testing process upon which successful testing relies.Document a contact who has taken responsibility for executing the Risk Mgmt Approach.

Risk ImpactProbability

Status Priority

Approach toManage,

Mitigate, orAccept

Responsibility

Access to the QAenvironment andits availability area primary risk tothe scheduledcompletion oftesting.

Possibleschedulemodificationswith potential toaffect delivery.

Med Identified High

Constantcommunicationbetween andCompany Xpersonnel toensuredowntimeimpact isminimized.

The Company X

Point of Viewmodificationsconflict with a requiredchange.

Possible delayin completion oftesting andimplementation

Low Identified Medium

Ensureadequate

testing ofHPOV changesprior to addingon changes.



15/21

Test Plan

Risk ImpactProbability

Status Priority

Approach toManage,

Mitigate, orAccept

Responsibility

BRD/TDDDocuments have

not been created,peer reviewed,approved andpresented to TestManagementbefore the SITphase begins.

Possible delayin completion oftesting andimplementation

High Identified High

Coordinate withPM to ensuretimely deliveryof requireddocuments

etc

.C CommunicationDescribe how communication of test status, reporting, and issue escalation will be handled.

.1 During Test Planninga. Weekly Workgroup Meeting Discussionsb. Purpose - develop and communicate test plans, develop and finalize test tools, processes

and cases.

.2 During Test Execution.a Daily Test Status / Incident Review Meetings

Purpose To review test status and logged incidents, review script execution status

Daily status updates will be provided with the Daily Test Status Meeting

.b Email (for status updates)Email

Purpose - to provide status of file transmission, script execution, balancing activities

.c Escalation Procedures

Purpose - to provide contacts and procedures to whom and how issues and/or incidents

should be communicated

.D Change ManagementDescribe how project changes which affect Testing will be handled. Usually there is an overall projectChange Control process, but if not, it may be necessary to put in place a Change Control processspecifically to manage changes to the test effort.

Ensure Change Control for the testing process appropriately complies with the overall ConfigurationManagement process for the project/effort.

All change request activity will be managed through the assignment of Primary Contacts at each ofthe project contributors whereby each will have a resource on point to quickly escalate, evaluate andmobilize in regard to any changes which impact approved requirements or have commercialramifications. The primary contacts are as follows:

o Company X Project Team,

o Project Team,



16/21

Test Plan

Changes which affect testing must be reviewed and approved by the Test Coordinator and CompanyX Project Manager.

.E Success MeasurementsHow will you know when testing has been successful? Note that success is not necessarily the same ascompletion; testing may be completed, but not necessarily considered successful.

Each test script will identify the appropriate criteria for success or failure for the test script.

High Level Success Measures for overall testing success:

All cases are written from reviewed and approved BRD and TDDs

All cases are successfully executed as planned

All cycles and conversions are processed on schedule.

All severity code 1 incidents are corrected within 8 business hours

All critical severity code 2 incidents have been corrected or acceptable work around procedures

have been documented, approved by management and distributed so that implementation maytake place on time

All outstanding concerns identified during User Acceptance Testing signoff are addressed

All workarounds documented and included in Employee Training Successful transition of outstanding incidents to production support teams

All functional/business and technical requirements have been met and related components

coexist without any issues.

.V Defect Management

Describe how Incidents and Defects will be tracked and managed. Note that an Incident/Issue/Anomaly isnot necessarily a Defect! It may be necessary in this section to separate Incident Management intodistinct Defect Management and Issue Management processes.

The below language is the standard Test Management incident process. Adjust to meet project orcontractual needs.

.A DefectTracking/Reporting ProcessEach individual / team conducting testing will report and relay any new incidents/issues to the overalltesting coordinator. By tracking all reported incidents, the Project Team will be able to monitor anyimpact(s) on the users, clients and/or customers.

Both incidents and issues will be reported to and tracked by the overall testing coordinator. Thedifference between the two categories is defined here.

Issue Definition: An issue is a formally defined matter that may or may not affect progress of the project,and about which no agreement has been reached. These are usually manifested in procedural difficultiesand minor equipment problems. This is usually an unresolved question, which could take the project in

many different directions, as a consequence should be monitored. Issues will not always pertain directlyto the project it will be important to track issues beyond the scope of the project, which may impact theproject.

Incident Definition: An incident is any discrepancy that affects the normal operation and completion of agiven activity. In addition, any event that will or could disrupt normal production or safety of ouremployees should be reported as an incident.

The individual who discovered the incident will enter incidents to the chosen testing tool.



17/21

Test Plan

The quantity and severity of incidents/issues will determine what action, if any, is necessary. Additionalcommunications may be developed, or support may be deployed, if the incidents warrant such action.

Daily incident reports will be generated for review during the Daily Test Status / Incident ReviewMeetings.

.1 Process ComponentsBecause some incidents may need to be reviewed and resolved by Engineering, the process willhave the following components:

.a Incident Logging, Reporting and Assignment All new incidents will be logged as they occur by(Company X Test Administrator) who will review the incident and supporting documentation to determineand or affect the following actions:

o Determine if the defect and/or supporting documentation relate to, or contain

sensitive data and/or information that should not be made available outside of the and or Company X firewalls. (i.e. Screenshots, excerpts, error logs etc.w/sensitive data)

o Should the defect and/or supporting documentation relate to, or contain sensitive

information as described herein, the documentation must be sanitized to secure allsuch information prior to processing the incident.

o Determine who the incident should be reported to.

o Review or determine incident severity level as described within this document

o The Company X Test Administrator will load and link all approved and properly

sanitized support documentation into the Product Support system.o The Company X Test Administrator will manage the distribution of confirmation email

messages as they are received following the submittal of a defect.o The Company X Test Administrator will monitor the defect resolution process

regularly to help ensure proper issue closure.

.b Incident Tracking For each item that is logged into the system (seeAppendix D), a tracking number will be assigned by the system. It is critical that all parties refer to this

tracking number when referring to a defect throughout the resolution process. Incidents/defects will beassigned severity codes as depicted in the table below.

.c Incident Resolution Incidents identified during the course of testing will be forwarded to theappropriate development resource for resolution via a Company X TPR form that will be completed by thetester discovering the issue. Once the completed TPR form has been forwarded to the developmentteam, the development team will be responsible for determining a proper resolution, recording it in theTPR form, making the appropriate repairs and or modifications to the code, and then forwarding allassociated information back to the test team for patch and re-testing.

.d Software Update Process Once an incident has been determined to be an incident, it will be loggedinto the Company X TPR Tracking system and assigned a priority based on severity level. All severitylevel 1 items are assumed to be preventing testing from continuing and will be resolved as quickly aspossible with a software solution provided by patch, if applicable. All other items will be resolved based

on priority and provided in the next applicable build. Software updates in the testing environment will bemanaged and approved by the Company X Project Test Coordinator.



18/21

Test Plan

.2 Severity Levels by Risk FactorsThere are two risk factors utilized to calculate severity levels, failure impact and fault probability.Failure impact and fault probability should be used as criteria for Severity levels and prioritizationof features to be retested. The matrix shown below is provided for the purpose of feature orcomponent prioritization. Failure impact includes scope of use and mission criticality and faultprobability includes technical and interface complexity.

Severity Levels Risk Factors Review /Response

SoftwareDelivery

(if applicable)

Definitions

Severity I High Impact, HighProbability

Same Day 24 Hours Show stopperIncidents that halt thetesting effort and has noworkaround.

Severity II High Impact, LowProbability

48 Hours Next ScheduledBuild

Incidents that have anegative impact ontesting and a workaround is available butwill only be temporaryuntil a permanent fix is

built.Severity III Low Impact, HighProbability

72 120 Hours Future ScheduledBuild

The incidents that havea good work around, butstill need to be fixedwithin a reasonableamount of time. (A goodexample would beperformanceimprovement issues.)

Severity IV Low Impact, LowProbability

Future Revision Future Revision Usually smallenhancements to thesystem that may beincluded in future builds.

.B Assigning Priority vs. Severity Levels

The big difference between Priority levels and Severity levels is the key process areas view of the defecttracking process. The Severity levels are bias toward testing and development and main focus is on howthe defect impacts the code and/or the total system. Severity Levels should be the result of root causeanalysis. Priority Levels are based on the business logic. The main focus is how the defect impacts thecustomers business and how often are they going to see this defect.


I II

III IV

Fault Probability

Failure

ImpactHigh

LowHigh Low


19/21

Test Plan

It is possible to have Severity I that does not need be fixed due to scheduling or areas of code that havebeen planned for reengineering, etc. We wouldnt change the Severity Level, but would add it to therequirements for the future effort and make it a priority 3 or 4. It is also possible to have Severity 3s and4s that are a Priority 1. Sometimes our clients have certain functionality that needs to be fixed when theywant it fix no matter what the impact to the system is. A good example is a cosmetic change or static textchange.

Listed below are Priority Levels that correlate to the Risk factors in the Severity Levels above.

Priority Levels Risk Factors Definitions

Priority 1 High Impact, High Probability A Show stopper that has a negativeimpact on a large segment ofcustomers. There is no effectivework around.

Priority 2 High Impact, Low Probability Incidents that have a negative impacton customers, or associates. A workaround is available but it is notfeasible (customer impact, cost,SLOC regulation, weather).

Priority 3 Low Impact, High Probability Incidents that identify an operation,which will need to be resolved, butoperate normally until such time ofresolution.

Priority 4 Low Impact, Low Probability Incidents that are nice to have buthave minimal to no negative impact tocustomers or associates.

.C Reporting DefectsWhen reporting an issue or incident, it is important to relay all the pertinent information. The list below isa guideline for information to include (and will be updated based on the incident tracking software chosenby the project):

1. Your name and contact telephone number, group or line of business2. The date and time the incident has occurred3. Title (Site Name Incident: x or Update to Site Name Incident: x)4. Detailed description of incident, including; current status, employee impact, customer

impact and severity (severity code definitions are listed below)5. Contact information of those involved, if applicable6. Workaround proposed or implemented7. Offer to send via fax or e-mail, if possible, any supporting information to theincident

Incidents/Defects will be assigned severity codes as described in section above:

Incident submission, updating, and closing instructions will be developed after the incident trackingsoftware has been chosen. There will be specific timing and cutoff rules to support effective andefficient review of incidents.

Defects will be documented and assigned to individuals for resolution. After resolution, corrections will bere-tested and the results verified



20/21

Test Plan



21/21

Test Plan

AppendicesProvide documentation (linked or embedded) referenced above. Also provide (linked or embedded) anysupporting documentation not directly referenced, but which supplies additional information regarding thetest process.

The documents below are typical.

.A Test Case / Script Template

.B Project Test Methodology Acronyms ListIt is very important to clearly define all the terms and acronyms on a project, especially since the TestPlan may be read by a Client who is not familiar with the technical and Company X-specific terms andacronyms which may be used on a project.

BA Business Analyst

BAU Business as Usual

BRD Business Requirements Document CDS Common Data Store

CMM Capability Maturity Model

CTC Client Test Coordinator

HRBP Human Resources Business Partner

HRMS Human Resources Management System

KPI Key Performance Indicator

PM Project Manager

PSDM Process Service Delivery Manager

PTC Project Test Coordinator

QA Quality Assurance

QAT Quality Assurance Testing

QC Quality Control RFC Request for Change

RTM Requirements Traceability Matrix

SDLC Software Development Life Cycle

SEPG Software Engineering Process Group

SIT System Integration Testing

SME Subject Matter Expert

SOW Statement of Work

SR Service Request

TDD Technical Design Document

TEM Test Execution Matrix

TPR Test Problem Report

TTC Transition Test Coordinator

UAT User Acceptance Testing

ULP Unique Line Processes

UT Unit Testing