PeopleSoft Test Strategy and Plans

PeopleSoft Test Strategy and Test Plans

Our last article – 4 Types of PeopleSoft Testing – outlined the four primary types of PeopleSoft testing. This staged approach to PeopleSoft testing represents a solid testing methodology. This article reviews PeopleSoft test strategy and PeopleSoft test plans, documents to set and execute a formal PeopleSoft testing process.

A PeopleSoft test strategy will help you avoid ineffective testing. You do not want a system that has a level of defects unacceptable to your organization. A test strategy, once created, enables a common understanding of the system functionality and the performance requirements needed to meet your business objectives. The purpose and content of a PeopleSoft Test Strategy document, and a sample template to outline all recommended content, follows this introduction.

Since each type of testing has its own purpose and focus, PeopleSoft test plans are developed for each stage: Unit, System/Integration, Performance, and User Acceptance. These test plans support the test strategy, and define upfront all aspects of the tests to be performed. We will outline the purpose and requirements of solid test plans, and provide a sample template in this area as well.

Beacon has been implementing and upgrading PeopleSoft applications since 1992. Over the years, we have found it a great time saver to incorporate testing planning and strategy in the earliest stages of the overall project planning effort. 

PeopleSoft Test Strategy

Your test strategy document defines the goals, policies, approach, and skills required for each testing stage planned. Each organization has its own standards (or tolerances). And each project has its scope, budget, and time frame.

The strategy document outlines the critical success factors for each testing stage and the criteria for success. These criteria can be measured against test results and standards documented for approval.

It also includes the assumptions for the testing process, the issues and risks involved, the resources to be used and the test assets – scenarios, cases and scripts – that will be used.

Each type of testing identified has its own purpose and focus. These should be specified in sequence. Each member of the testing team needs to be the appropriate resource for each particular test. (Technical personnel unit test a customization, while a business user must be responsible for System/Integration and User Acceptance testing to ensure that the customization not only works, but works to the specifications of the business need.)

Lastly, testing is only as good as the tester. Within the Test Strategy document, it is important to specify how testers will be trained, that they have necessary tools and support documents to perform the test, and that they understand the process for reporting non-conformance and re-test procedures. 

Success factors outlined in your strategy document should accommodate each stage of testing and should include items such as:

• Successful completion of all on-line test plans.
• Successful completion of all background test processes.
• Successful completion of all inter-application (integration) test scenarios and processes, or designation of acceptable work-arounds.
• Acceptable on-line response time is experienced during Performance/Volume testing. (Note:  Acceptable response times must be agreed upon and documented prior to testing.  Different processes may have widely different acceptable levels of response depending upon the criticality of the function and the frequency with which it is required.)
• Background processes can be executed within the available batch processing schedule, where applicable.

PeopleSoft Test Plans

Once a test strategy is in place, a formal test plan should be documented to include an overview of how the plan supports the strategy, success factors and criteria, assumptions, issues and risks, deliverables from testing, resources/test teams, preparation (including training) necessary for successful testing, a test schedule and expected results from your testers. 

It is important to assign personnel responsible for independent oversight of testing.  This person, or these individuals, will be responsible for overall coordination of the test phases.  They will be reviewing and confirming actual test results and verifying that tests have the designated conditions necessary for the next test cycle, and that all tests were executed to plan. They will also be summarizing the process results and Test Results Report.  These personnel may in fact be different groups depending on the testing stage you are executing.  As you approach system and UAT testing, these individuals will also ensure that there is coordination and monitoring of testing efforts not only within but between applications or modules. They will also be responsible for ensuring that the testers workstations have the proper release levels of dependent software (excel, browser, etc) for testing.

Your test plan document that outlines the test schedule must also consider the deadlines and due dates established for each test component to keep testing on track.  In order to meet your deployment date, the test schedule will include:

• Training Deadline
• Migration Deadline (for each environment used in testing)
• Data Input Deadline
• Distribution of Test Plans
• Conduct Tests
• Logs Due
• Test Results Report Due
• Test Results Report Approved

In addition to the above documentation of the approach, roles, responsibilities and schedule, your document will include procedures that will

• Identify how actual results should be documented (i.e., hard copies, print screens, collect Test plans and index them in a notebook, automated test tool test results)
• Identify the procedures for documenting and tracking problems encountered during testing (i.e., help desk support, communication flow)
• Specify how you will log incidents to record and track problems encountered during testing.
• Determine the Resolution path for problems and issues
• Define ‘Severity’ for the Incident Log

• Critical = This is a problem which causes a "stop work" situation, where there is no functional work-around and testing process is halted. Since this type of problem is a critical error, problem resolution must be immediate.
• High = This severity level is assigned when the problem restricts operation of an important system function impacting the business process, procedures, controls or public image. Testing may be interrupted for the particular function, but other testing can be continued. 
• Medium = This problem does not interrupt testing for the particular function, and other testing can be continued.
• Low = These errors represent minor problems or cosmetic errors and do not affect the overall operation of the application. It will be up to the functional staff to assign further priorities to the rectification of these types of errors.

In sum, creating and documenting standards through the formulation of a Test Strategy and Test Plan will not only produce a solid, reliable system but will serve as an anchor throughout the lifecycle of your usage of the system.  It will provide a proof statement to your auditors and management team that processing is reliable and achieving the goals of the organization.