[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]

iSIS Testing Strategy

Since all functions within Campus Solutions are interwoven, there is a need to test the software from the design stage to on-going maintenance. The Testing Strategy covers set-up tables, self-service, reporting, batch processes, security, conversion, and documentation of the Campus Solutions modules, as well as all business processes as they relate to the phased implementation approach adopted by the LASER project. The project team will create scenarios (test cases) and test scripts (test data) to be used in all types of testing.

Unit Test validates the individual components of the software will function as a stand alone unit and that implementation at the module level is free from defects. This test is performed between the developer and the Subject Matter Expert (SME). The SME will test business processes by creating test scripts and scenarios.

Integration Testing confirms whether or not the software is operating properly as each sub-process is added. Individual software components, modifications, interfaces, self-service, security roles and reports in iSIS are tested and then combined with other pieces to ensure all data, data sharing and links are working as specified in the new processes documentation.

The top-down method of integration testing will be used because many of the processes must build upon each other to produce system-level behavior. Integration testing is more about testing K-State processes, set-up values, modifications, interfaces, and data delivery, and not about the software itself.

User Testing permits the administrative user an opportunity to test the software. Administrative users will be involved with learning the functionality and understanding how it fits with their business tasks. The project team will conduct Fit/Gaps and Design and Prototype sessions to determine the needs of the administrative users. Any modifications, interfaces, and reporting that are identified will need user sign off before being finalized.

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.

Goals and Benefits

  • Test all modifications, interfaces, data delivery, and conversion.
  • Test all components and self-service related to the phased implementation process, including load and stress testing on processes that will impact performance of the system.
  • Validate all business processes, set up tables, rules, parameters and security.
  • Identify, document, and report errors for resolution prior to implementation. Confirm that the error has been successfully resolved before implementation.
  • Document all business processes, modifications and interface specifications, set-up tables, test scripts, test scenarios, conversion, self-service, data delivery (reporting) and store in a central repository, to be used for any regression testing of future upgrades, regulatory updates, fixes and the current implementation.

Testing will ensure a stable production environment since errors will be remediated before the software is implemented. Testing will also decrease implementation time as SMEs will have a clear understanding of requirements as they develop test scripts and create process documents/maps with testing in mind. Testing will decrease risk, as processes that impact performance will be tested as close to a production environment as possible.

Assumptions

  • Test Scripts will be developed by the users or SMEs based on K-State’s business processes as determined by the LASER Team through their To-Be Processes.
  • Necessary project team members (includes core team and members from key departments) will assist with resolving any problems discovered during testing.
  • All business processes, business requirements, set-ups, modifications, interfaces, reports, and business cycles that are to be tested have been defined, developed, and unit tested before testing begins on a business process and its components (i.e.: mods, interfaces, requirements, etc.)
  • Train project team to use testing tools and testing methodology such as Quick Test Pro and/or Test Director.
  • Prioritize testing efforts, testing critical and major processes as early in the schedule as possible.

Requirements

  • Test environment and instance for Campus Solutions is kept up-to-date with all upgrades, set-up tables and patches as in the production database.
  • Conversion data and test data will be reloaded to the test environment “by request” after any refresh.
  • Test environment should be as close to production as possible including process scheduler, database, application and web servers for adequate load testing.
[an error occurred while processing this directive]