Testing has an essential, if not a crucial role in the implementation process. All functions are interwoven and face a need to be tested from the design stage to on-going maintenance.
This Test Strategy is for Student Administration and will be used to test and validate the functional and technical requirements, set up tables, self-service, reporting, batch processes, security, conversion, and documentation of the four modules within Student Administration: Admissions, Student Records, Student Financials and Financial Aid. This includes testing successfully all business processes as they relate to the “Phased Implementation” approach adopted by the STARS project. The testing team will, in conjunction with functional teams, create test cases (scenarios) and test data to be used in all types of testing.
Unit Test will validate that the individual pieces of the software function as a standalone unit and that implementation at the module level is free of defects. This test is performed between the developer and the Subject Matter Expert. Subject Matter Experts will also test “business processes” by creating test scripts and test cases (scenarios.)
Integration Testing will determine if software operates properly as each sub-process is added. Individual software (PS components, modifications, interfaces, self-service, security roles and reports as part of a To-Be sub process) is tested and then combined with other software (PS components, modifications, interfaces, self-service, security roles and reports as part of a To-Be sub process) to make sure all data, data sharing and links are working as specified in the To-Be Process.
The top-down method of integration testing will be used. Many of the processes must build upon each other to produce system-level behavior. We will not be “testing” PeopleSoft software, but our processes and set up values in PeopleSoft as well as our modifications, interfaces, PS delivered reporting and RDS canned reporting.
User Testing permits the user, not a tester an opportunity to test the software. Usually by the time we get to system testing, it is too late to user test. Users must be involved from the beginning with the PS functionality and understand how that fits with the way they do business. The project team will conduct Fit/Gaps and IDP (Interactive Design and Prototype) sessions to determine the needs of the users. They will determine where the fits are and where the gaps are and modifications, interfaces and reports have been defined. We will not be “testing” PeopleSoft software, but our processes and set up values in PeopleSoft as well as our modifications, interfaces, self-service, security roles and data delivery. Modifications, interfaces, and reporting will need user sign off, especially for interfaces to other systems.
System Testing takes place once we have determined that the integrated processes have been successfully tested, the system test will begin in a whole (all SA and eventually HR, CR and Payroll) system environment.
Load Testing is used to test an application against a number of users. Stress Testing is load testing over an extended period of time to validate an application’s stability and reliability. It will also need to be determined if the system is processing the correct information at high speed.
Testing will ensure a stable production environment, as thorough testing will find errors that are remediated before the software is implemented. Testing will decrease implementation time as SMEs will have a clear understanding of requirements as they develop test scripts, create process documents/maps with testing in mind and work with users. Testing will decrease risk, as processes that impact performance will be tested as close to a production environment as possible.
Test Director will be used by:
LoadRunner will be used by CIT and the Testing Team to run the load tests
QuickTest Pro will be used by the Test Designer and Tester to create and run automated testing.
The Testing Team’s main responsibility is to ensure that all Student Administration functional and technical requirements have been successfully tested at each sub-process (to include PS components, modifications, interfaces, security roles, self-service and reports) and then combined with other software (PS components, modifications, interfaces, self-service, security roles and reports as part of a To-Be sub process) to make sure all data, data sharing and links are working as specified in the To-Be Process. Many of the processes must build upon each other to produce system-level behavior. We will not be “testing” PeopleSoft software, but our processes and set up values in PeopleSoft as well as our modifications, interfaces, security roles, PS delivered reporting, RDS canned reporting and BrioLite models. This includes documenting and reporting any errors to developers or functional lead for remediation and re-execution of tests until successfully resolved.
The Testing Team will also coordinate system testing activities with the other modules (HR, CR and Payroll) and CIT, including load and stress tests around critical processes (example: Enrollment during a Payroll) used in the modules. The Testing Team is also responsible for working with Subject Matter Experts (SME) to create test scripts and test cases as the SME build and unit test the To-Be Process. These test scripts and test cases will be used for testing at implementation and for regression testing after we implement.
The Testing Team will also conduct a conversion validation for all converted data into Student Administration. This includes documenting and reporting any errors for remediation and re-execution of conversion validation until successfully resolved.
The Testing Team will also work with technical (CIT), security and set-up table support to maintain the system infrastructure to ensure that all tables, security roles, updates and fixes have been applied to the testing environment.