Professional Documents
Culture Documents
System Testing Approach
System Testing Approach
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.
Document1
Page 1 of 12
8/5/2013
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
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.
Document1
Page 3 of 12
8/5/2013
Document1
Page 4 of 12
8/5/2013
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
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
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.
Document1
Page 7 of 12
8/5/2013
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.
Document1
Page 8 of 12
8/5/2013
Document1
Page 9 of 12
8/5/2013
A. Glossary
Application Bug Business Function
Development Team
Document1
Page 10 of 12
8/5/2013
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
Document1
Page 12 of 12
8/5/2013