INTRODUCTION:
Consultants (guilty!) and vendors (guilty again!) have come up with a variety of PeopleSoft test kits and sample or pre-built scripts to accelerate and jump start the heck out of your testing efforts. This is not a new idea: Beacon and Rational Software released the SQA Test Foundation for PeopleSoft in 1997.
This post is not focused on the merits (or drawbacks) of these offerings. Rather, it is intended to give you some perspective regarding your PeopleSoft testing in terms of
Some of these points will be obvious, but taking a step back to look at the fundamentals of PeopleSoft testing is a good place to start any assessment. Testing can be resource intensive, so upfront consideration of process, people, and your current capabilities is warranted.
There are three main areas of focus when testing PeopleSoft applications.
The primary emphasis in application testing should be on validating application data. Configuration data sets various options for processing, transaction data is the result of the processing. Security data controls access - that users do have access to necessary and permitted data, and do not have access to restricted data.
The tests that validate this data involve running Jobs - PeopleCode/Cobol/AppEngine - that utilize the configuration data in producing the transaction data and reports. You're not "testing the data" -you're testing the process that uses/produces the data. As much as possible, these processes should mirror the steps, frequency, and all the scenarios you encounter, or expect to encounter, in production.
When processes run, if the configuration data does not produce the predetermined "expected" transaction data/results, the next step is to ascertain the data is correct. Any anomaly can then be identified as a bug by rerunning the process in DEMO.
The short answer to Why Test? is to confirm the system produces "expected results". In other words, not just that it "works" and runs without errors, but that it works and produces expected results..
You don't test to just see if Payroll runs. You test to see if Payroll runs correctly under a variety of scenarios (weekly, bi-weekly, quarterly, year-end) for a variety of processes, including taxes, deductions, and so on. And you want to check that everything works with different employee groups, including Executive Payroll, Retired, hourly workers, and so on.
There is a long list of things that need testing, and there should be a list of all the tests, and assignments, and steps for remediation when error occur. Effort is necessary to organize and co-ordinate the tests. Each test and test case is a building block. Many tests are mundane and/or straight forward (and appropriate for automation).Testing enterprise systems is a team sport, involving people, process, and tools.
The degree of testing, both in terms of depth and breadth, will depend on the type and complexity of the change.
Good testing, appropriately deep and broad, usually involves some combination of automated testing and manual testing. User Acceptance Testing, for large changes before deployment, should always be done manually. (Automated SIT testing can ensure turning over a solid working system to UAT.)
Automated testing can be especially appropriate in areas of high volume, repetitive tests. For example, it is possible to manually test the rules for combo-edits in GL, or approvals in Purchasing and Absence Management, but it would be impossible to test manually all the valid or invalid combinations, or that all requests for all approvals are properly routed to the right person(s), just due to the large number of values, employees and managers.
CONCLUSION:
Testing PeopleSoft applications involves validating configuration and transaction data by running PeopleSoft processes that simulate production scenarios. The scope and depth of testing depends upon the scale of the change(s), and usually involves both manual and automated processes.
Policies and processes for PeopleSoft testing change under the PeopleSoft Update Manager model, usually suggesting that more frequent, but smaller changes be anticipated, planned for, and tested.