Time+and+Labor+Management+Test+Plan+v11

Information Services

Time and Labor Management System

Quality Assurance Test Plan

Prepared by: IS Quality AssurancePrepared date: September 18, 2008Doc version: 1.0

Information Services Quality Assurance Test PlanTime and Labor Management System

Revision Log

Date Revision # Author Change Description

9/18/08 1.0 Original

Page 2 of 21This information is proprietary & confidential - For PGW internal use only

© 2008 PGW. All rights reserved.


ApprovalsPlease review and acknowledge your acceptance of this document by signing and dating in the table below. By signing below, you signify agreement with the requirements contained in this document for the PGW Time and Labor Management System project.

If you have any questions or concerns regarding this matter, please contact the IS Project Manager.

Title Name Signature Date

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

Page 3 of 21This information is proprietary & confidential - For PGW internal use only

© 2008 PGW. All rights reserved.


Table of Contents

1. OVERVIEW........................................................................................................51.1 Objectives..............................................................................................................................51.2 Risks......................................................................................................................................61.3 Contingencies........................................................................................................................61.4 Assumptions..........................................................................................................................71.5 Test Environment And Test Tools.........................................................................................9

2. TEST SCOPE...................................................................................................102.1 Functions That Will Be Tested............................................................................................102.2 Functions That Will Not Be Tested.....................................................................................11

3. TEST STRATEGY............................................................................................113.1 System Test..........................................................................................................................113.2 User Acceptance Test..........................................................................................................123.3 Test Coordination................................................................................................................13

4. CONTROL PROCEDURES..............................................................................144.1 Test Plan Review.................................................................................................................144.2 Defect Review Meetings......................................................................................................144.3 Change Requests..................................................................................................................144.4 Test Result Verification.......................................................................................................15

5. TEST SCHEDULE............................................................................................156. DEFECT REPORTING.....................................................................................15

6.1 Defect Life Cycle.................................................................................................................156.2 Priority Levels and Recommended Corrective Actions......................................................16

7. RESOURCES...................................................................................................178. SYSTEM TEST PROCESS..............................................................................189. SUSPENSION / EXIT CRITERIA......................................................................1914. REFERENCES.................................................................................................1915. ACRONYMS AND ABBREVIATIONS...............................................................20

Page 4 of 21

This information is proprietary & confidential - For PGW internal use only© 2008 PGW. All rights reserved.


1. OVERVIEW

PGW has performed a preliminary assessment of the potential workload required to efficiently

manage all organizational labor resources in real time. This assessment has determined that the

workload will be beyond the capability of the existing PGW applications. The aim of this project is

to implement a new Time and Labor Management System designed to help PGW organization

manage, collect, and distribute time and attendance data automatically as well as monitor labor

activities as they happen to better control labor costs with reliable, up-to-the-minute tracking of labor

data.

The purpose of this Test Plan is to outline necessary activities to ensure that the objectives of implementing the new Time and Labor Management System have been met and are aligned to meet PGW needs and to ensure conformance of the new system with PGW requirements. In addition, the Test Plan serves to identify potential risks and weakness in controls as well as solutions to mitigate risks and strengthen controls.

1.1 Objectives

The Quality Assurance Test Plan for the Time and Labor Management System supports the

following objectives:

1.1.1 To define a methodology and strategy of test that will be used to validate and verify

functionality of the delivered system.

1.1.2 To detail the activities required to prepare and conduct System and User Acceptance

Tests.

1.1.3 To identify test coverage for all requirements listed in the Functional Requirements.

1.1.4 To define testing schedule and to determine and coordinate responsibilities and resources

involved in the testing.

Page 5 of 21



1.1.5 To define environment and test cycles required to effectively complete System and User

Acceptance Tests.

1.1.6 To define all system functions to be tested as well as those functions that will not be

tested.

1.1.7 To identify potential risks and weakness in controls as well as solutions to mitigate risks

and strengthen controls.

1.1.8 To identify Entrance and Exit criteria for the System and User Acceptance Tests.

1.2 Risks

1.2.1 Insufficient internal resources to support project. Project team members may be

redirected to other projects during Time and Labor Management project.

1.2.2 The new system is not acceptable or it is inadequate replacement for the existing system.

1.2.3 The new system does not integrate with other PGW systems

1.2.4 Insufficient, inadequate or incorrect requirements/supporting documentation.

1.2.5 If the new system is not delivered to PGW’s Quality Assurance in a stable condition, the

number of problems found during testing could result in a delay in production

implementation.

1.2.6 Due to the aggressive schedule, it is very important to have experienced testers on this

project. Unexpected turnovers can impact the schedule. If attrition does happen, all

efforts must be made to replace the experienced individual.

1.3 Contingencies

1.3.1 Asses what positions required in project can be outsourced or borrowed from the client

area. Hire external consultants where applicable.

1.3.2 Continue to utilize current systems and processes. Reprioritize requirements to deliver

enhancements in the next phase of a project.

Page 6 of 21



1.3.3 Validate technical analysis, conduct thorough integration testing, or develop alternate

technical solution.

1.3.4 Validate specifications with the end user. Continue to use a current system while

gathering more detailed requirements for the enhancements defined for the next phase of

the project.

1.3.5 If some major functions are deemed by the Quality Assurance/Business Matter

Expert groups to be significantly unstable or the Business Requirements were

misinterpreted, those functions will be identified and returned to the vendor for

system correction and stabilization.

1.3.6 Management support is required when the project falls behind, so the test

schedule does not get squeezed to make up for the delay. Management can reduce

the risk of delays by supporting the test team throughout the testing phase and

assigning people to this project with the required skills set.

1.4 Assumptions

A number of assumptions have been made upon which the successful completion of

the project may depend. Some assumptions are more critical than others; however, all

have some bearing on the project success. Should any of these assumptions not hold

true, the impact will need to be assessed at the time they become evident and

appropriate adjustments or actions taken.

1.4.1 All applications, systems, interfaces and resources required to fully support the Time and

Labor Management System must be available on 10/6/08.

1.4.2 Each individual Quality Assurance Analyst has required access to the Time and Labor

Management System as well as access to the required hardware equipment, such as Card

Reader device.

1.4.3 All relevant system documentations will be made available to Quality Assurance

Department on or before 8/7/08.

Page 7 of 21



1.4.4 Unit Test has been completed by the vendor prior to commencement of System/User

Acceptance Test.

1.4.5 All required data will be pre-loaded and reviewed by the designated PGW

representative(s).

1.4.6 Production data migration procedures will be completed prior to the beginning of the

testing phase.

1.4.7 Customizations of interfaces, reports and other required functionality as defined in the

Software Requirements Specification / contract will be tested and approved by the

designated PGW representative(s).

1.4.8 File transfer mechanisms to/from Time and Labor Management System will be

completed prior to the System Testing phase.

1.4.9 The test environment(s) will be functional and available during all scheduled test

activities throughout all the test phases.

1.4.10 Scheduled system downtime will be communicated to the test team to reallocate activities

accordingly.

1.4.11 Test location will be in Philadelphia, PA.

1.4.12 All required parties have access to the PGW’s internal Issues Tracking System (Quality

Center).

1.4.13 All PGW resources will be available by the date required on the test schedules to begin

the testing.

1.4.14 Software will be delivered on time.

1.4.15 Software is of the required quality.

1.4.16 All "Show-Stopper" defects receive immediate attention from the vendor.

1.4.17 Functional and Technical Specifications will be signed off by project stakeholders.

1.4.18 No further changes will be considered for inclusion in the release except (1) When

permission has been given by the PGW Change Management Board (2) When the

changes will not require significant effort on behalf of the test team and will not

adversely affect the test schedule. This is a potentially serious issue, as any major

changes to design will entail additional time to re-plan testing and to create or amend test

conditions and scenarios.

Page 8 of 21



1.4.19 The source code will be tested by the Workforce.

1.4.20 The Quality Assurance Team and Business Matter Experts will have access to all

modules and functions of the system specified in the Functional Requirements and to the

database.

1.4.21 All the card readers and IVR phones should work as expected. Printer and phone system

should be provided to support communication.

1.4.22

1.5 Test Environment and Test Tools

1.5.1 Employee Center Hosting Server.

1.5.2 Time Clocks (via Hardware VPN connection to the Employee Center Hosting Server).

1.5.3 Oracle Financials Server (via SFTP connection to the Employee Center Hosting Server).

1.5.4 LDAP Authentication Server (via Hardware VPN connection to the Employee Center

Hosting Server).

1.5.5 AIMS Server (via SFTP connection to the Employee Center Hosting Server).

1.5.6 ADP Hosting Server (via SFTP connection to the Employee Center Hosting Server).

1.5.7 Timesheets and Web Clocks (via HTTP or HTTPS connection to the Employee Center

Hosting Server).

1.5.8 Six networked workstations with Windows XP and Internet Connection via Internet

Explorer 6.0, 7.0 and Fire Fox 2.X., one of which will be dedicated to Performance and

Load testing.

1.5.9 IVR phones.

1.5.10 Twenty User Id’s and Passwords (minimum 15 users will be used to emulate 15 different

employee types).

1.5.11 Quality Center 9.0 – internal Issues Tracking System.

1.5.12 MS Office Tools (MS Word/MS Excel)

1.5.13 TOAD, PL SQL Developer

Page 9 of 21



2. TEST SCOPE

All the Test Scripts and Business Test Scenarios will be developed and mapped based on the

Functional Requirements document. The Test Scripts will be created so they can be executed

independently. Every Test Script will be traceable to the requirement it covers.

2.1 Functions That Will Be Tested

2.1.1 Employee Type (3.1)

2.1.2 Roles (3.2)

2.1.3 Assignment Group (3.3)

2.1.4 Delegation (3.4)

2.1.5 Timesheet (3.5)

2.1.6 Time Collection Devices (3.6)

2.1.7 Grace Period (3.7)

2.1.8 Rounding (3.8)

2.1.9 Labor Distribution (3.9)

2.1.10 Premiums (3.10)

2.1.11 Lunch (3.11)

2.1.12 Pay Calculation (3.12)

2.1.13 Fair Labor Act (FLSA) (3.13)

2.1.14 FMLA (3.14)

2.1.15 Time off and Tracking Accruals (3.15)

2.1.16 Sick Certification (3.16)

2.1.17 Overtime Equalization (3.17)

2.1.18 Time off Requests (3.18)

2.1.19 Schedules (3.19)

2.1.20 Holidays (3.20)

Page 10 of 21



2.1.21 Amended Timesheet (3.21)

2.1.22 Approvals (3.22)

2.1.23 End of Period Processing (3.23)

2.1.24 Employee termination (3.24)

2.1.25 Authentication (3.25)

2.1.26 Reports (3.26)

Note: The number shown in the parenthesis corresponds to the number of section in the Functional

Requirements document.

2.2 Functions That Will Not Be Tested

2.2.1 System interfaces.

2.2.2 Hardware interfaces.

2.2.3 Time Clock device locations.

2.2.4 Pre-populated timesheet and schedules implementation rules.

2.2.5 Schedule templates and rotation creation.

3. TEST STRATEGY

The Test Strategy consists of a series of different tests that will fully exercise functionality and

performance of the Time and Labor Management System. The primary purpose of these tests is to

uncover the system limitations and measure its full capabilities. The tests that will be executed

against the Time and Labor Management System are explained below.

3.1 System Test

System Test of the Time and Labor Management System and its interfaces will be conducted to

evaluate the system's compliance with the requirements specified in the Functional Requirements

document. Since the new Time and Labor Management System is an “Off The Shelf Software”, the

Page 11 of 21


, 09/25/08,

Mamta,I corrected a few verbiage last night. I don’t see them reflected here. Actually I don’t see any of my changes reflected in the sections below. Did you copy paste the wrong version?


System Test will fall within the scope of a black box testing, which requires no knowledge of the

inner design of the code or logic. The Integration Testing will be conducted also to detect any

inconsistencies between the software units that are integrated together or between any of the

assemblages and the hardware as well as to detect defects both within the "inter-assemblages" and

within the system as a whole. The System Test will be performed on the entire system in the context

of a Functional Requirements but will focus to have almost a destructive attitude and test not only

the design, but also the behavior and even the believed expectations of the customer.

The Test Scripts will be executed against the system as well as screen mapping and error messages

testing. Overall, the system test will test the integrated system to validate the following:

3.1.1 The system meets PGW Business requirements.

3.1.2 The Functionality delivered by the vendor, is as specified in the Functional

Requirements.

3.1.3 The software is of high quality;

3.1.4 The software supports the intended business functions and achievess the standards

required by PGW for the development of new Time and Labor Management System.

3.1.5 The new system interfaces correctly with ADP, AIMS, LDAP and Oracle Financials

applications.

3.2 User Acceptance Test

The purpose of the User Acceptance Test (UAT) is to obtain confirmation by Business Matter

Experts, through trial or review, that the system meets mutually agreed-upon requirements. UAT

will act as a final verification of the required business function and proper functioning of the system,

emulating real-world usage conditions on behalf of the paying client. If the system works as intended

and without issues during normal use, one can reasonably infer the same level of stability in

production. The User Acceptance Test will be performed by Business Matter Experts or end-users

with the assistance of Quality Assurance Group. The UAT will not focus on identifying simple

problems such as spelling errors and cosmetic problems, nor show stopper bugs, such as software

Page 12 of 21


http://en.wikipedia.org/wiki/Crash_(computing)

http://en.wikipedia.org/w/index.php?title=Show_stopper_bug&action=edit&redlink=1

http://en.wikipedia.org/wiki/Subject_Matter_Expert

http://en.wikipedia.org/wiki/Subject_Matter_Expert

http://en.wikipedia.org/wiki/Destructive_testing

http://en.wikipedia.org/wiki/Functional_requirements

http://en.wikipedia.org/wiki/Black_box_testing


crashes, which will be identified and disposed during the System Test. The overall result of the UAT

should give confidence to the Business Matter Experts as to how the Time and Labor Management

System will perform in Production. There may also be legal or contractual requirement for

acceptance of the system. Once the Time and Labor System is ready for testing, the Business Matter

Experts need to create business test scenarios that are traceable to the Functional Requirements and

perform User Acceptance Test.

3.3 Test Coordination

The test coordination between Business Unit and Quality Assurance Group is highly needed during

the testing of the Time and Labor Management System to ensure the entire test process runs

properly. The test coordination during the System Test phase will be performed by the Test

Coordinator, selected from the QA Team. The test coordination during the User Acceptance Test

will be performed by the Test Coordinator selected from the Business Unit. All the test coordination

issues will be addressed in daily Defect Review and Test Status meeting.

The responsibilities of Test Coordinators from both teams include the following:

3.3.1 Design and develop test scenarios based on the collections of business scenarios.

3.3.2 Design test procedures that include a collection of test scenarios and test scripts to cover

the newly implemented features and changes, as well as many general scenarios that

would broadly exercise other features of the system.

3.3.3 Design variations of test scenarios as needed.

3.3.4 Identify test parameters at scenario level, where the individual transactions occur. (Test

parameters can include extreme values, error conditions and error handling, failure

scenarios and how to detect them, and alternatives to be invoked when failures occur.)

3.3.5 Depict data to be used during testing in detail and determination of data sets required to

exercise each of the test scenarios.

Page 13 of 21


http://en.wikipedia.org/wiki/Crash_(computing)


3.3.6 Assign roles to each tester to focus on particular test scenarios and data sets. If there are

enough testers, it would be optimal to assign more than one person to cover each test

scenario, as each person will approach it differently.

3.3.7 Establish a test schedule for both, manual execution of test scripts and batch jobs, to

allow enough time for multiple rounds of testing and to coordinate the schedules of

individual testers for each round in which they will be participating.

3.3.8 Set up and conduct test progression check points to ensure the overall success of the test

cycles.

3.3.9 Participate in Change Management Board.

3.3.10 The assigned Business Matter Experts will coordinate the execution of the test scripts

within their units, and will log any issues found during the testing.

4. CONTROL PROCEDURES

4.1 Test Plan Review

The Project team will perform reviews of Test Plan. Each aspect important of Test Plan will be

discussed in the meeting. A meeting notice, with related documents, will be emailed to each

participant.

4.2 Defect Review and Test Status Meeting

Daily meeting will be held in QA Lab to discuss reported defects and go over test status. The

Project team will provide statuses or updates on all defects reported and the QA and Business team

will provide additional defect information if needed. All Business and QA testers will participate.

4.3 Change Requests

Once test begins, changes to the Time and Labor System are discouraged. If functional changes are

required, these proposed changes will be discussed with the PGW Change Management Board

(CMB) and Change Request defect review meeting will be held. The CMB will determine the

impact of the changes and if/when they should be implemented.

Page 14 of 21



4.4 Test Result Verification

In some occasions, business knowledge is required to verify the test results. The following Business

Matter Experts may be involved in the verification process.

4.4.1 HR, Payroll and Finance Experts.

4.4.2 ADP and Oracle Financials Experts.

4.4.3 AIMS Experts.

5.

6. TEST SCHEDULE

# Task Start Date End Date

1 System Training 09/29/08 10/1/08

2 Quality center training 10/2/08 10/2/08

3 System Test 10/6/08 10/31/08

4 User Acceptance Test 10/02/08 10/31/08

7. DEFECT REPORTING

All the defects will be reported in QC 9.0 by QA and Business and training for reporting defects in Quality center will be provided to Business (Diane Lashley, Bob Haeberle, Mark Valentino and Anne Breyer, Sherry Pennington) by QA Team.

The defect tracking Systems will be accessible by QA and Business Team

7.1 Defect Life Cycle

When defect is detected, the QA and Business Team will report defect in Quality Center 9.0 as a

new Defect (with attached screenshots and detailed steps to reproduce that defect) and assign it to

Workforce.

Page 15 of 21



7.1.1 New defect raised By QA or Business testers – NEW. When the defect is posted for the

first time, its state will be “NEW”. This means that the defect is not yet reviewed by Workforce.

7.1.2 Workforce accepts and opens defect - OPEN

7.1.3 After a tester has reported a defect, Workforce reviews and assigns the defect to a

developer. Workforce can reject the defect due to the following reasons, duplicates,

invalid test scenario, out of scope test scenario, non-reproducible issue or incomplete test

information - REJECTED.

7.1.4 If A new defect cannot be resolved at the point of time – DEFERRED. The reasons for changing the

defect to this state have many factors. Some of them are that the defect may not have major impact

on the software or the resolution is pending decision from PGW CMB.

7.1.5 The defect is fixed by Workforce – FIXED. Once the defect is fixed and the status is

changed to Fixed, the tester needs to retest the defect and verify if it is fixed or not. If the

defect is not fixed, tester will reopen the defect and assign to Workforce.

7.1.6 The defect is resolved. – CLOSE. When the defect has been verified fixed or is no longer

valid, tester will close the defect.

7.1.7 Defect still exists in the system – REOPEN. Tester will reopen a defect from Fixed

status when fix is failed. In the situation of reviewing a rejected defect, tester can reopen the defect

when more information has been added to prove that the defect is valid.

7.1.8 Any new changes are required in software - CHANGE REQUEST. If new features /

changes are required, the defect will be changed to Change Request status. PGW CMB

will review all Change Request defects.

7.2 Priority Levels and Recommended Corrective Actions

If a defect is determined to have emergency impact, it means the problem causes the software, a

workstation, or network to crash. It may also mean the problem results in corrupt data, or

Page 16 of 21


, 09/25/08,

Replace bug with defect.


produces incorrect or severely misleading results in an environment that is typical for the

customer.

The term 'workaround' means an alternative method can be used to obtain the same functionality.

Emergency: An item that prevents further testing of the product or function under test can be

classified as critical. No workaround is available.

High: A defect that does not function as expected/designed or cause other functionality

to fail to meet requirements.

Medium: An issue that affects a non-critical requirement.

Low: A cosmetic issue that affects a non-critical requirement

8. RESOURCES

The following Project Team members will be involved in testing:

Project Manager/Lead - Anne Breyer

Business Lead - Diane Lashley; Mark Volentino; TBD

UAT Testers – All required attendees in Test plan meeting on 10/26/08

QA Manager - Jackie Qian Zhou

QA Testers – Gennadiy; Ramya; Mamta

External Test Support Team – Workforce

Page 17 of 21



9. SYSTEM TEST PROCESS

The above diagram outlines the System Test approach that will be followed.

1. Requirement Analysis: Involve gathering all the information and documents related to

the system and request/assign resources.

2. Design System Test Plan: Involve designing test plan, creating Test Scripts,

identifying Test Cycles, Test Strategy, Test Sets, Entrance & Exit Criteria etc.

3. Design Test scripts: Include designing of test scripts according to the Functional

Requirements.

Page 18 of 21


4. Test caseTest Script Review

3. Design Test Scripts

6. Test caseTest Script Execution

7. Reports and Analysis

8. Sign Off

2. Design System tTest Plan

1. Requirement Analysis

5. Workforce Demo and Training


4. Test Script review: Include Test Script review by PGW Business and QA Team.

5. Workforce Demo and Training: Workforce will present a demo and process flow

information to the PGW Project Team, and provide training to trainers and testers per

agreement between Workforce and PGW Project Team.

6. Test Script Execution: Include details of manual Test Script Execution.

7. Reports and Analysis: Include setting up template in Quality Center 9.0 and status

report, requirement coverage, defect review meeting.

8. Sign Off: Sign Off is required when all pre-defined exit criteria have been achieved.

10. SUSPENSION / EXIT CRITERIA

If any defects are found which seriously impact the test progress, the QA manager may choose to

suspend the test.

Criteria that will justify test suspension are:

Hardware/Software is not available at the times indicated in the project schedule.

Source code contains one or more critical defects, which seriously prevents or limits

testing progress.

Assigned test resources are not available when needed by the test team.

If testing is suspended, resumption will only occur when the problem(s) that caused the suspension

has been resolved. When a critical defect is the cause of the suspension, the “FIX” must be verified

by the tester before testing is resumed.

REFERENCES

1. Functional Requirements version 4.0

Page 19 of 21



2. Black, Rex; (2002). Managing the Testing Process (2nd ed.). Wiley Publishing. ISBN 0-471-

22398-0

3. IEEE standard for software test documentation IEEE Std 829-1998 Volume , Issue , 16 Dec

1998

14. ACRONYMS AND ABBREVIATIONS

ADP: Advance Payroll

AIMS: Advance Intelligence Mobile system

CAT Fund: Catastrophic fund

CMB: Change Management Board.

FLSA: Fair Labor standards Act

FMLA: Family Medical Leave Act

G/L: General Ledger

I/O: In/Out

IVR: Interactive Voice Response

LDAP: Labor Distribution Application

LD: Labor Distribution.

OT: Over Time

QA: Quality Assurance

QC-Quality Center

RDO: Regular Scheduled Day Off

TOR: Time Off request

SME: Subject Matter Expert

UAT: User Acceptance Test

Page 20 of 21


http://en.wikipedia.org/wiki/Special:BookSources/0471223980

http://en.wikipedia.org/wiki/Special:BookSources/0471223980


Page 21 of 21


Date post:	22-Nov-2014
Category:	Documents
Upload:	girlmoss
View:	108 times
Download:	0 times

Time+and+Labor+Management+Test+Plan+v11

Documents