Time and Labor Management Test Plan v11

Information Services
Time and Labor Management System

Quality Assurance Test Plan
Prepared by: IS Quality Assurance

Prepared date: September 18, 2008
Doc version: 1.0
Information Services Quality Assurance Test Plan
Revision Log
Date Revision # Author Change Description
9/18/08 1.0 Original
Page 2 of 33
This information is proprietary & confidential - For PGW internal use only
© 2008 PGW. All rights reserved.
Approvals
Please 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 33
Table of Contents
OVERVIEW.............................................................................................................................5
1.1Objectives.....................................................................................................................................5
1.2Risks.............................................................................................................................................6
1.3Contingencies...............................................................................................................................7
1.4Assumptions.................................................................................................................................7
Test Environment and Test Tools ...................................................................................................11
.....................................................................................................................................................12
2.TEST SCOPE....................................................................................................................12
2.1Functions That Will Be Tested...................................................................................................12
Functions That Will Not Be Tested.................................................................................................14
TEST STRATEGY.................................................................................................................14
15
System Test.....................................................................................................................................17
User Acceptance Test......................................................................................................................17
2.2 Test Coordination......................................................................................................................18
CONTROL PROCEDURES..................................................................................................19
Test Plan Review............................................................................................................................20
Defect Review and Test Status Meeting.........................................................................................20
Change Requests.............................................................................................................................20
2.3Test Result Verification..............................................................................................................20
TEST SCHEDULE................................................................................................................21
DEFECT REPORTING ........................................................................................................23
29.1 Defect Life Cycle....................................................................................................................23
29.7Priority Levels and Recommended Corrective Actions .........................................................25
RESOURCES.......................................................................................................................26
SYSTEM TEST PROCESS..................................................................................................27
SUSPENSION / EXIT CRITERIA .......................................................................................28
REFERENCES......................................................................................................................30
ACRONYMS AND ABBREVIATIONS..................................................................................31
Page 4 of
33
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:
Page 5 of
33
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.
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.
Page 6 of
33
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.
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
Page 7 of
33
Page 8 of
33
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.
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.
Page 9 of
33
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.
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
Page 10
of 33
Test Environment and Test Tools
1.4.23
1.4.24 Employee Center Hosting Server.
1.4.25
1.4.26 Time Clocks (via Hardware VPN connection to the Employee Center Hosting Server).
1.4.27 Oracle Financials Server (via SFTP connection to the Employee Center Hosting Server).
1.4.28 LDAP Authentication Server (via Hardware VPN connection to the Employee Center
Hosting Server).
1.4.29 AIMS Server (via SFTP connection to the Employee Center Hosting Server).
1.4.30 ADP Hosting Server (via SFTP connection to the Employee Center Hosting Server).
1.4.31 Timesheets and Web Clocks (via HTTP or HTTPS connection to the Employee Center
Hosting Server).
1.4.32 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.
Page 11
of 33
1.4.33 IVR phones.

1.4.34 Twenty User Id’s and Passwords (minimum 15 users will be used to emulate 15 different
employee types).
1.4.35 Quality Center 9.0 – internal Issues Tracking System.
1.4.36 MS Office Tools (MS Word/MS Excel)
1.4.37 TOAD, PL SQL Developer
1.4.38
1.4.39
1.4.40
1.4.41
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
2.1.3 Roles (3.2)
2.1.4
2.1.5 Assignment Group (3.3)
2.1.6
Page 12
of 33
2.1.7 Delegation (3.4)

2.1.8
2.1.9 Timesheet (3.5)
2.1.10
2.1.11 Time Collection Devices (3.6)
2.1.12
2.1.13 Grace Period (3.7)
2.1.14
2.1.15 Rounding (3.8)
2.1.16
2.1.17 Labor Distribution (3.9)
2.1.18
2.1.19 Premiums (3.10)
2.1.20
2.1.21 Lunch (3.11)
2.1.22
2.1.23 Pay Calculation (3.12)
2.1.24
2.1.25 Fair Labor Act (FLSA) (3.13)
2.1.26
2.1.27 FMLA (3.14)
2.1.28
2.1.29 Time off and Tracking Accruals (3.15)
2.1.30
2.1.31 Sick Certification (3.16)
2.1.32
2.1.33 Overtime Equalization (3.17)
2.1.34
2.1.35 Time off Requests (3.18)
2.1.36
Page 13
of 33
2.1.37 Schedules (3.19)

2.1.38
2.1.39 Holidays (3.20)
2.1.40
2.1.41 Amended Timesheet (3.21)
2.1.42
2.1.43 Approvals (3.22)
2.1.44
2.1.45 End of Period Processing (3.23)
2.1.46
2.1.47 Employee termination (3.24)
2.1.48
2.1.49 Authentication (3.25)
2.1.50
2.1.51 Reports (3.26)
Note: The number shown in the parenthesis corresponds to the number of section in the Functional
Requirements document.
Functions That Will Not Be Tested
2.1.52 System interfaces.

2.1.53 Hardware interfaces.
2.1.54 Time Clock device locations.
2.1.55 Pre-populated timesheet and schedules implementation rules.
2.1.56 Schedule templates and rotation creation.
TEST STRATEGY
Page 14
of 33
Page 15
of 33
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.
Page 16
of 33
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
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:
2.1.57 The system meets PGW Business requirements.

2.1.58 The
2.1.59 Functionality delivered by the vendor, is as specified in the Functional Requirements.
2.1.60 The software is of high quality;
2.1.61 The software supports the intended business functions and achievess the standards
required by PGW for the development of new Time and Labor Management System.
2.1.62 The new system interfaces correctly with ADP, AIMS, LDAP and Oracle Financials
applications.
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
Page 17
of 33
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
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.
2.2 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.
Page 18
of 33
The responsibilities of Test Coordinators from both teams include the following:
2.2.1 Design and develop test scenarios based on the collections of business scenarios.
2.2.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.
2.2.3 Design variations of test scenarios as needed.
2.2.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.)
2.2.5 Depict data to be used during testing in detail and determination of data sets required to
exercise each of the test scenarios.
2.2.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.
2.2.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.
2.2.8 Set up and conduct test progression check points to ensure the overall success of the test
cycles.
2.2.9
2.2.10 Participate in Change Management Board.
2.2.11
2.2.12 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.
CONTROL PROCEDURES
Page 19
of 33
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.
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.
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.
2.3 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.
2.3.1 HR, Payroll and Finance Experts.

2.3.2 ADP and Oracle Financials Experts.
2.3.3 AIMS Experts.
Page 20
of 33
3.
4.
5.
6.
7.
8.
9.
10.
11.
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
12.
13.
14.
15.
16.
Page 21
of 33
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
Page 22
of 33
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
29.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.
29.2
29.2.1
29.2.2
29.2.3
29.2.4
29.2.5
29.2.6
29.2.7
29.2.8 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.
29.2.9 Workforce accepts and opens defect - OPEN
29.2.10 After a tester has reported a defect, Workforce reviews and assigns the defect to a
developer.
Page 23
of 33
29.2.11
29.2.12 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.
29.2.13
29.2.14 If
29.2.15
29.2.16
29.2.17 A new defect cannot be resolved at the point of time – DEFERRED.
29.2.18
29.2.19 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.
29.2.20
29.2.21 The defect is fixed by Workforce – FIXED.
29.2.22
29.2.23 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.
29.2.24
29.2.25 The defect is resolved. – CLOSE.
29.2.26 When the defect has been verified fixed or is no longer valid, tester will close the
defect.
29.2.27
29.2.28
29.2.29 Defect still exists in the system – REOPEN.
29.2.30 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.
29.2.31
Page 24
of 33
29.2.32 Any new changes are required in software - CHANGE REQUEST.

29.2.33 If new features / changes are required, the defect will be changed to
Change Request status. PGW CMB will review all Change Request defects.
29.3
29.4
29.5
29.6
29.7 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
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
Page 25
of 33
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 26
of 33
SYSTEM TEST PROCESS
2. Design 4. Test caseTest

1. Requirement 3. Design Test
System tTest Script
Analysis Scripts
Plan Review
5. Workforce
Demo and
Training
6. Test
caseTest Script
Execution
7. Reports and
8. Sign Off
Analysis
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.
4. Test Script review: Include Test Script review by PGW Business and QA Team.
Page 27
of 33
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.
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.
Page 28
of 33
Page 29
of 33
REFERENCES
1. Functional Requirements version 4.0

2.
3. Black, Rex; (2002). Managing the Testing Process (2nd ed.). Wiley Publishing. ISBN 0-471-
22398-0
Page 30
of 33
4. IEEE standard for software test documentation IEEE Std 829-1998 Volume , Issue , 16 Dec
1998
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 31
of 33
Page 32
of 33
Page 33
of 33

Time and Labor Management Test Plan v11

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Time and Labor Management Test Plan v11

Transféré par

Droits d'auteur :

Formats disponibles

Information Services

Time and Labor Management System

Prepared by: IS Quality Assurance

Title Name Signature Date

Test Environment and Test Tools

1.4.33 IVR phones.

2.1 Functions That Will Be Tested

2.1.1 Employee Type (3.1)

2.1.7 Delegation (3.4)

2.1.37 Schedules (3.19)

Functions That Will Not Be Tested

2.1.52 System interfaces.

2.1.57 The system meets PGW Business requirements.

User Acceptance Test

2.2 Test Coordination

Test Plan Review

Defect Review and Test Status Meeting

2.3 Test Result Verification

2.3.1 HR, Payroll and Finance Experts.

# Task Start Date End Date

29.1 Defect Life Cycle

29.2.32 Any new changes are required in software - CHANGE REQUEST.

29.7 Priority Levels and Recommended Corrective Actions

The following Project Team members will be involved in testing:

SYSTEM TEST PROCESS

2. Design 4. Test caseTest

SUSPENSION / EXIT CRITERIA

Criteria that will justify test suspension are:

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

1. Functional Requirements version 4.0

ACRONYMS AND ABBREVIATIONS

ADP: Advance Payroll

AIMS: Advance Intelligence Mobile system

Vous aimerez peut-être aussi