Testing must be an on-going activity throughout all phases of a project and should be an integral component of quality assurance efforts. A complete testing strategy cannot be developed until after vendor selection, so this section contains suggestions for possible activities that could be included in a testing strategy, and a general description of the types of testing Project Manager should consider. A complete testing strategy and plan must be developed once the project reaches the implementation planning phase. The Project Workbook should be updated by the Project Director to include the Test Plan, once it is finalized.

Testing starts at the unit level, as team members test portions of the functionality encompassed within a single module, interface, report or modification. Data modeling is used to test delivered functionality. Customizations, interfaces and reports are first tested by their developer before they are submitted for testing by functional users. Functional users will conduct a unit test of the customization, report or interface and formally accept it before it is moved to production.

As the implementation of the project progresses, so does the nature of testing. After each module has been thoroughly unit tested, integration testing begins. As integration testing proceeds, more end-user participation is needed. Project Management Office (PMO) recommends that there be one person (a central point of contact or testing coordinator) responsible for tracking the status of test scripts and the documented results of each test. Any test scripts which identify errors should be tracked and given to the appropriate person to resolve. After the error has been resolved, it should be re-tested by the same individual who originally uncovered the error.

The next step in the testing cycle is to carry out system testing, to validate that the entire system performs as expected. Given concerns voiced by members of the user community over an “all or nothing” cutover, Project Manager may choose to perform a modified parallel test. In this scenario test scripts are created using two to four weeks of live data from a previous month. The output from the scripts (including process, interface and reporting outputs) is compared to the output from the legacy system. Unexpected discrepancies will be analyzed, resolved, and re-tested. This cycle is repeated until the team (and the user community) is confident that the new system is ready for production.

Each module Project Team should develop detailed test plans and acceptance criteria. These plans will be integrated and coordinated for the testing of inter-module processes. The plan should also identify one or more Testing Coordinators.

Test Scenarios

A test scenario documents the scope of a testing effort. It identifies the portion of the system being tested, which major functions or areas are to be tested, the approach to be used, the resources assigned, and the expected outcome of the testing. One or more test cases will be defined to accomplish the defined test scenario.

Test Cases

A test case describes the data and the process steps required to test a portion of the system for correctness, in support of a test scenario. A test case defines the specific functions to be tested, any base data that must be present prior to testing, data that will be input during the test, the process steps to be performed to accomplish the test, and the expected outcome from the test in the form of expected data results and deliverables. Test cases should be established for both functional and technical testing.

Test cases are also referred to as test scripts. As these test scripts are completed they serve as a good foundation for documentation and training.

Test cases should be designed to be reusable – individual test cases should be used as a component of later business process and integration testing, and should use the same general format as training and documentation materials.

Functional Testing

Functional tests allow the institution to validate the utility and accuracy of end-user processes. To accomplish functional tests, users run through a process from end to end. For example, the user looks up data, enters new data, executes system processes (interfaces or batch updates), generates output (reports or queries), and verifies the results of the test.

Technical Testing

A technical expert defines a technical test to ensure that the system operates correctly from a technical and performance standpoint. This involves the technical specialist verifying that the system operates correctly, that interfaces are correctly developed, that data loads correctly, that control tables are loaded, and that any system fixes are applied and operate correctly. Technical testing should also include load testing to ensure that system performance (including network, server and client architecture) meets expectations.

Unit Testing

This is a test with a narrow scope, relating to the test of a single module, a conversion process, an interface, a report or query, or any other single component of the system. This test can be both a technical test and/or a functional test, with the task owner taking responsibility for configuration and base documentation.

Integration Testing

An integration test verifies the correctness of several system components working together. An ERP system implementation typically includes integration testing and acceptance

• At the time the delivered system is installed and configured with basic institutional data,
• After any customizations and custom interfaces or processes are developed,
• And as part of test conversions prior to deployment, to ensure that the system works properly with all customizations and legacy data in place.

This test includes both technical and functional testing, validating the ability of the system components to “talk” to each other and pass data correctly. Each iteration of integration testing fosters user ownership and knowledge transfer.

Planning for intermediate sign-off points also ensures that errors are caught and corrected at the right time. For example, performing an integration test immediately after basic installation and configuration identifies errors in configuration or system bugs. Correcting these early allows later integration testing to focus on errors in customization or data conversion.

System Testing

The system test validates that all aspects of the system are functional. This will require both functional and technical testing, and should also include a system stress or load test. The stress test will assess the ability of the system to handle expected production-size volumes.

Security Testing

Security testing validates that each type of user profile provides access to the correct areas of the application, and that data inquiry and update controls behave as expected. Security testing should include validating a user’s access to the online application, and any relevant batch or reporting processes the user should be able to execute. The security test must also validate that technical and project team members have appropriate access to development environments, but that both data and processes in the eventual production environment are properly secured. As such, the security test should be specifically defined within the context of the database environment.

Date Testing

Date testing is designed to test the system’s response to data-sensitive transactions.

Acceptance Testing

The main function of Acceptance Testing is to validate that a given module or function meets end-user expectations, and that no further development or correction is required. User acceptance tasks should be included as milestones in the project WBS, and serve several important functions:

• Acceptance validates that the work in a given area is 100% complete,
  and will not be revisited,
• Acceptance gives end users a chance to interact with, approve and begin to “own” a function or area,
• Any re-work discovered after acceptance constitutes a scope change, and must be handled through the issue and change control processes.

Acceptance testing should be performed at the completion of each major (i.e.: requiring many days effort to complete) functional module, customization, interface or report. The acceptance test is not necessary for low-effort tasks, but in any situation where re-work would cause significant project schedule, resource or budget disruption, or where dependent processes would be significantly impacted, the acceptance test is a necessary quality assurance step.

The final acceptance test is the testing of the full system after it has been placed into a “non-live” production environment. This test can include performing the same tests used during the system test, and may include a mini parallel test with data loaded into both the new and legacy system so that results can be cross-checked and validated. Upon user satisfaction with the final acceptance testing, the new system goes into production.

www.bestitdocuments.com