Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document

System Test Approach

I. Introduction
This testing approach document is designed for Information and Technology Services upgrades to PeopleSoft. The document contains an overview of the testing activities to be performed when an upgrade or enhancement is made, or a module is added to an existing application. The emphasis is on testing critical business processes, while minimizing the time necessary for testing while also mitigating risks. Its important to note that reducing the amount of testing done in an upgrade increases the potential for problems after go-live. Management will need to determine how much risk is acceptable on an upgrade by upgrade basis.

A. Purpose of Testing
Testing ensures that the system still meets the client needs (functional requirements). The intent of System Test is to find defects and correct them before go-live. There is no approach or method to guarantee a system completely free of defects. However, following a System Test approach will assist in mitigating risks and ensuring a successful project.

B. Assumptions
There is a detailed listing of assumptions in Section IV. For System Testing to be successful, there are critical work efforts that need to be accomplished in the preceding phases, Requirements/Analysis, Design and Development.

II. Test Approach

A. Test Approach Description
The general methodology/approach for PeopleSoft Upgrade System Testing at ITS will involve the following steps: 1. 2. 3. 4. 5. Both a minor and major upgrade will test all the critical business functions at least once. Confirm the key contact list (lead matrix) is updated. Review reports needed for tracking System Testing, update if necessary. Review the issue management process, update if necessary. Confirm the test conditions, cycles, and plans based on functional requirements are updated. Plans should include conditions for testing users security access. 6. Ensure test conditions are grouped by business process. There should be a separate test plan that follows a transaction through the entire system versus just at the entry or exit point. (End-to-end test plan). 7. Confirm the interface listing worksheet is updated. (For HE - This worksheet lists all external interfaces, which are files that are received or sent, outside of HRMS and SA.) This should include all database links and the access granted (i.e. Read Only, Read/Write, etc).

Document1

Page 1 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
8. Confirm the critical path business processes are updated. 9. Identify any risks that may jeopardize the schedule completion. 10. Review with Central Offices; obtain Acknowledgment of System Test Plan(s). For each Phase of System Testing: 11. Execute the test condition. 12. Check the output against the expected results. 13. Evaluate and document any unexpected results. Utilize testing incidents database. 14. Make sure that any required corrections are migrated and re-tested. 15. Make sure that final testing components (conditions, input, and expected results) are accurate, complete and documented in such a way to make them repeatable and reusable. 16. Review and obtain Acknowledgment of System Test results where appropriate (i.e. new functionality).

B. Test Phases
There are separate phases of testing which are designated on the timeline within the overall System Test phase. Each phase may include several types of testing. The level of testing for an upgrade is more condensed and may not be as time-consuming as for an implementation. When possible, some of these phases may be done concurrently. The following is a list of the test phases included in the overall System Test timeframe. However, some of these phases are not covered in detail in this document. There are separate Approach documents for those noted. The types of testing listed in SIT1 and SIT2 are described in the table in the following section. System Integration Testing I (SIT1) This phase includes integration, system, user testing, security, some end-to-end, and regression test types. All RTP conditions with a criticality of A and those with a B and a High or Medium level of change will be tested. Refer to the Upgrade Prioritization Approach Document for details on the RTP prioritization. The testers may include Developers, CPU Business Analysts, ITS Help Desk, Business Process Owners and End Users. System Integration Testing II (SIT2) This phase includes regression testing (all failed SIT1 conditions), end to end, batch, system, integration, and user testing. All RTP conditions that are Low Bs and Cs will be tested, per module discretion. Refer to the Upgrade Prioritization Approach Document for details on the RTP prioritization. The testers may include Developers, CPU Business Analysts, ITS Help Desk, Business Process Owners, and End-Users. Note: There is a separate Approach document for Batch testing. Parallel Testing

Document1

Page 2 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
This phase validates all processes work together to support the business functions to ensure successful payroll runs. There is a separate Approach document for this testing effort. Load Testing This phase validates that critical functions will meet production performance requirements during peak transaction volumes. There is a separate Approach document for this testing effort. Model Office This phase enables end-users an opportunity to log into the system, perform their typical tasks on the new system, verify their security access, validate their procedures and get comfortable with the new system. This phase is scheduled after the hard-freeze and if additional defects are found during this phase, migrations will require additional levels of sign-offs. Participation in this phase is at the discretion of each module. There is a separate Approach document for this testing effort. Infrastructure/Gateway Testing There is a separate Approach document for this testing effort.

C. Testing Type Descriptions

The following is a list of test types that will be performed during SIT1 and SIT2:

Test Type Integration Testing

Focus

System Testing

End-to-End Testing

Regression Testing

Testing to find errors in complete functions and processes within and between units. Ensure everything has been linked together correctly. Validate that the system functionality performs as SIT1 & SIT2 specified. Functional requirements define how the system should perform. Validate a transaction through the entire system, not SIT1 & SIT2 just at entry and exit points. This means a transaction is followed throughout the various modules it may touch. Must be coordinated. SIT1 & SIT2 Ensures that the application doesnt negatively impact previously migrated objects/modules. Re-tests the application to ensure that a fix did not cause another portion to break that was previously working. This is done as objects are migrated to fix errors.

System Test Phase SIT1 & SIT2

Document1

Page 3 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
Test Type Security Testing User Testing Focus Eliminates security accessibility errors. Same focus as Integration and System Testing (executing RTP conditions), performed by Users. Also, validates production-ready and data integrity. Note: There is no separate User Testing phase how users are incorporated into the overall testing effort may vary by module. This is the opportunity for users to validate functionality prior to the hard freeze. System Test Phase SIT1 & SIT2 SIT1 &/or SIT2 per module discretion

III. Status and Reporting Metrics

A. Defect Tracking Approach
During all phases of system testing, defects will be logged into the Lotus Notes Testing Incidents database, including performance tuning needs. The database will provide the necessary information for developers, as well as provide management with reports. The developers need the name of the reviewer, date discovered, the requirements, test case id, severity code, and any other relevant information. All high and medium priority issues must be resolved or have a work-around in place to go-live. To ensure timely resolution of cases submitted to PeopleSoft during the system test phase, the SIT lead will be provided a contact at PeopleSoft.

B. System Test Phase Tracking Approach Metrics to Utilize

System test will be tracked by phase and within each phase the business processes by module. Leads will be responsible for ensuring that time is entered into Planview and all stats are reported to the system test phase lead in a timely manner. The format of the status reports being utilized for design and development will be used for system testing, as well as the reusable test plan reports. There may be additional reporting requirements, as well as, the CPUs may have additional detailed reports. Metrics that will be tracked include but are not limited to: 1. Number of conditions, by priority (ABC), that are in progress, in error, passed, deferred, or not started. 2. Percentage of conditions tested. 3. Percentage of conditions passed.

Document1

Page 4 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
4. Percentage of A, B, and C conditions. (Including % of each priority that has been tested and passed.) 5. What cycle/sub-cycle the conditions are in. 6. Total number of conditions per cycle/sub-cycle. 7. Total number of conditions per priority. 8. Percentage of Effort Complete 9. Percentage of Effort Earned. 10. Percentage of Effort Remaining. 11. Number of Open Testing Incidents by priority.

C. System Test Status/Issues Meeting

During system testing, it is recommended that a weekly status meeting be held at the same scheduled time on the same day each week. This meeting will support a communication process to inform the project team on the testing status, problems or issues, and changes. The agenda will include a review of open high and medium issues, the overall system test plan, and any action items from the previous week. Meeting minutes should be taken that include a list of attendees, discussion points, and action items. Developers and reviewers should be represented in the meeting, as needed.

D. Acknowledgement
Where deliverables require acknowledgement, this means that the responsible party has reviewed the documentation, feels that the documentation and/or testing was sufficient. Prior to system testing, test plans will require acknowledgement. During system testing, test conditions will require acknowledgement if requested. Reports will be available to provide to the users regarding status of system testing.

IV. Assumptions and Risks for the Upgrade System Test Approach
A. Assumptions for System Test Approach
The following assumptions are critical to the successful accomplishment of this Approach to System Testing for the PS Upgrade: Upgrade Management:

Document1

Page 5 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
HE will use an Upgrade Management Database (UMDB) to capture critical data in all phases of the upgrade. Other CPUs may manage this differently.

Requirements/Analysis and Design The Requirements/Analysis phase will assess the upgrades impact on each business process area. The Requirements/Analysis phase will determine the prioritization needed for each business process for the following phases including Design, Development, and Test phases. The Requirements/Analysis phase will identify all cross module impacts and touchpoints within modules. The Requirements/Analysis phase will determine the timing of object level work efforts for the following phases (Design, Development and Testing). In some cases, the work may be done outside of the set dates for each phase, based on priority and dependencies. For example, a global change like the HE x-lat table change should be completely done prior to other changes being started. Reusable Test Plans (RTPs) will be updated as needed during Requirements/Analysis and Design phases. RTPs must be complete prior to the applicable System Test phase. The Requirements/Analysis phase will determine what Business Processes need to be included in Load Test and will identify Interfaces and Remote Database Access (RDA).

Data Conversion Validation Data conversion validation will be done during Test Moves as outlined in the Upgrade Practice Moves Approach.

Development If applicable, objects for Load Testing are completed prior to the beginning of the System Test phase, so initial system testing can be performed prior to Load Testing. As development occurs, necessary updates will be made to the RTPs.

Unit Testing Unit Testing tested the business processes that were modified by ITS (hand applies).

Test Plans Test Plans will include a level of detail necessary to enable them to be re-used for various test phases. Each module will have their System test plans complete by the start of each applicable phase. There will be a separate end-to-end test plan, which covers the entire business process. ODS and Data warehouse will have separate test plans and perform additional testing. Note: Modules should include test cycles for ODS and DW in their end-to-end testing.

Document1

Page 6 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
External interfaces to and from PS are identified with requirements and key contacts in the test plans. (Note: There is a separate document for this. The document will then indicate which cycle/sub-cycle/condition testes the interface.) Internal interfaces to/from specific PS modules are identified in the test plans. Listing of Database links and the access the links provide (Read, Read/Write or Update, Read/Write or Update/Delete) is provided with the test plans. Appropriate resources (Technical, Functional Leads, Help Desk Staff, Business Analysts, etc) assist in creation of test conditions, scripts (if applicable) and test execution.

Technical The System Testing instance is full copy/size of production, with production data. Batch jobs will be run during their normal Production times. A separate environment will be available for payrolls Parallel Test, and Load Test. The environments (Demo, Dev and Test/QA) will be functioning and available during all scheduled test activities. Adequate technical support will be provided to allow the team to meet the approved project schedule. Migrations into System Test environment will be coordinated through a release management plan. Any migrations after SIT2 will require additional signatures. Backups are occurring on a regular basis to ensure the ability to restore the database. Security setup will be complete prior to system testing beginning for the ITS and user testers. A plan for disaster recovery is in place. A separate project for updating the disaster recovery process, and testing that process will be performed independently of System Testing. It is outside of scope for the upgrade. Document naming and repository standards are established and followed. Plan for contention between SIT1, Parallel and Load testing (people and hardware). Testing will be performed via the web (not 2-tier or 3-tier, unless applicable). Technical resources will be available for performance tuning of critical processes.

Other

A contact at PeopleSoft will be available during SIT, for escalation and timely resolution, of high priority cases.

B. Risks for System Test Approach

Load testing and Parallel testing instances on same box as System Integration Test. Ability to coordinate timing of Load and Parallel testing. Reusable Test Plans not complete with test conditions defined. Production support responsibilities. Availability of Resources (technical and functional). Development not complete prior to the start of SIT1. Users not exposed to some form of training. Security is not setup up before testing begins.

Document1

Page 7 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
Peak processing times for CPUs during System Testing need to be reviewed.

V. Deliverables
A. Deliverables from System Test Phase Lead and Methodology Team
The following deliverables are required. Updated System Test Process Flows - if necessary (M 5000B System Test Phase Process Flow) Updated System Test Plan Template (Reusable Test Plan format), updated as necessary (M571 System Test Plan TEMPLATE) Updated System Test Approach Documents o o o o o Updated System Test Approach Document (Overview) (M 5000A System Test Approach) Updated Parallel Test Approach (M 5000A2 Parallel Test Approach) Updated Load Test Approach (M 5000A3 Load Test Approach) Updated Batch Test Approach (M 5000A4 Batch Test Approach) Updated Model Office Approach (M 5000A5 Model Office Approach)

Updated Problem Resolution Approach (included in system test approach documents). Updated Key Contacts List (Lead Matrix) (M520 System Test Contact Lists) Updated Metrics/Tracking Reports Updated High Level Overall System Test Plan Work Breakdown Structure (WBS)- Identify critical path, note where may have conflicts and cushions in timeframe.

B. Deliverables from Each System Test Phase

The following deliverables are required from each phase for it to be considered completed. Work Breakdown Structure (WBS) - updated business processes and adjusted hours. This is required at the beginning of the system test phase, in order to put the WBS into Planview for tracking and reporting. M571 System Test Plan o Master reusable test plan (RTPs) with appropriate rating scale assigned to each business process.

Document1

Page 8 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
o o o o o STAT TI (Testing Instance) Database (Resolution of issues or work around in place) Test scripts and process flows as necessary A subset of the RTP for SIT1 A subset of the RTP for SIT2/User Test the focus here is end-to-end testing. Model Office does not require a test plan, however one may be provided. It may be the same as used for SIT1, SIT2/User Test. All internal and external touch points/interfaces and key contacts must be identified.

Document1

Page 9 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document VI. Appendix
Is a set of software components that provide a business function. A fault or that portion of a program that fails under specific conditions. Also known as a defect. A single business activity such as claim entry or a major business function such as claim processing. A specific purpose or capability of an application. An order of steps or functions necessary to perform a major business function. The process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked. Also known as an application or subject matter expert assigned by the owner of the application. A person that possesses specific detailed knowledge of an application, system, or business process. In regards to testing, the individual(s) assigned to work with the development team in defining the test plan, developing acceptance test cases and conditions, and reviewing system and acceptance test results. A collection of data fundamental to a system or enterprise. Database administrator has the responsibility for those functions needed to manage data in a database Also known as a fault or bug, a defect is a portion of a program that, when executed under specific conditions cause a failure. A part of the software development process whose primary purpose is to decide how the system will be implemented. During design strategic and tactical decisions are made to meet the required functional and quality requirements of a system. The group of individuals with primary responsibility for code enhancement, upgrade, conversion, or development of a system application. This may include a manager, team leader, business analyst, technical analyst, technical coders, and DBA. A disagreement or inconsistency between the expected and actual results. An action that creates a defect also known as fault or bug. The actual result from the test case execution does not match the expected result. Portion of a program that when executed under specific conditions cause a failure. Also known as bug or defect. The tester is not a part of the development team who test based on the knowledge of the functional and performance

A. Glossary
Application Bug Business Function

Business Condition Change Control Procedures Client/Customer

Database DBA Defect Design Phase

Development Team

Discrepancy Error Failure Fault Independent Tester

Document1

Page 10 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
Interface requirements of the system. Any electronic exchange or sharing of data between applications. The applications may exchange information in a variety of methods. Directly, by sending or receiving data to/from each other via online connections. Data feeds such as magnetic media or electronic data interchange (EDI). Indirectly, by mechanisms such as placing files on a bulletin board, to be pulled by other applications. The interfacing applications may also share files accessible to both (e.g. master files), where by one application updates the data and the other reads it from the same file. A sequence through a program of statement or instructions that starts at an entry, junction, or decision and ends as another junction, decision, or exit. A concise and accurate description of the deliverables to be expected from the project and that meet specified requirements as agreed between the Project's Stakeholders. A walkthrough in which one leads one or more members of a development team through a deliverable to ask questions, note possible errors, standard violations or any other problem. Those responsible for ensuring a product is completed and fault free at a quality review. Specifies the types and levels of tests as well as test case techniques and strategies. A document describing the expected result and execution procedures for a specific input process. A collection of test cases stored in a library for future use and thus reduces development time. A set of measurements that define the success of a test. The sum of all technologies, tools, people, and procedures needed to carry out the testing events for an application. A document that contains verbiage to describe the test case and condition, inputs, expected results, dependencies, rating of risk, pass/fail criteria and the necessary details required to execute the test case. The process of exercising or evaluating a unit, component, system by manual or automated means to verify that it meets requirements or to identify differences between expected and actual results. The process of evaluating software at the end of a development process to ensure compliance with software requirements The process of determining whether or not the products of any given phase of the software development cycle meet the

Path

Project Scope

Review

Reviewers Test Approach Test Case Test Case Repository Test Criteria Test Environment Test Plan

Testing

Validation Verification

Document1

Page 11 of 12

8/5/2013

Information and Technology Services

PeopleSoft Upgrade Project

M 5000A1 - System Test Approach Document
requirements established during the previous phase.

Document1

Page 12 of 12

8/5/2013