PeopleSoft Testing is a Challenge, and the Challenge is Changing
PeopleSoft testing has long been a challenge. Often the main reason organizations defer changes or updates to applications is testing concerns. But the model for change is flipped with the introduction of PeopleSoft Update Manager (PUM) in release 9.2. Rather than large, infrequent upgrades, the new model implies more frequent, smaller changes, delivered in the update image(s).
This new "selective adoption" approach has many benefits, both for customers and Oracle, and this new delivery approach has implications for testing. (The delivery-bone's connected to the test-bone).
PeopleSoft testing is a broad topic. There are several different and unique types of testing, each accomplishing different purposes and used at different times. This post outlines the four primary types of PeopleSoft testing, to help you look at each aspect of your testing capabilities, and assess these aspects in your organization.
The 4 types of PeopleSoft testing:
1. Unit Testing
PeopleSoft Unit Testing focuses on testing modifications and new processes not delivered with the PeopleSoft applications. Unit testing can be as simple as testing the functionality of a new allocation, to a more complex test of a customization to the system.
The unit testing process for an implementation is naturally more intense because during an implementation, the unit testing process ensures that the interfaces, conversion programs, customizations, and reports meet their functional and technical design requirements.
The person creating the configuration, modification, or program usually performs unit testing. This testing includes verifying that the system correctly handles all of the organization's normal and usual business transactions and conditions. It also includes verification of the accuracy and reliability of the systems inbound and outbound interfaces.
Occasionally, people use the term "functional testing" when the unit tested is a functional unit, such as a report or a configuration.
Every new modification, report, process or configuration should be tested (and documented) by the "developer" of the new unit.
1.B PeopleSoft Application Testing
In a large implementation, Beacon usually performs/recommends an Application Testing step. Application testing focuses on the overall business cycle processes within an application to ensure that these business processes perform as designed. An application test is the test of a single application - GL, or AP, or Time and Labor. The test is performed when all configuration and development is complete as a "dry run" for System Integration Testing. We generally do not do application testing during an upgrade, unless new modules were implemented as part of the upgrade project.
2. System/Integration Testing (SIT)
PeopleSoft System/Integration Testing focuses on the overall use of the PeopleSoft application and the surrounding interfaces and processes. It focuses on both the online and batch processes and confirms that the PeopleSoft system meets all the needs of the business community. System testing exhausts full functionality, including all periodic processing (daily, weekly, monthly, quarterly, annually, and ad hoc). System/Integration testing includes all components:
- All PeopleSoft functionality
- Remote site processing
- Device processing (mobile, tablets)
- Local and remote printers
- Local and remote web servers
- Converted data
- Interfaced data
- Third-party software
The most important aspect of system testing is that it be close to the "real world", that the system test reflects the likely flow of data within and between PeopleSoft applications and other internal systems. In that respect, it should reflect periodic processing in the order and/or grouping that is likely to occur in a production environment. Likewise, while earlier unit testing will have focused on functionality verification, system testing also needs to take the infrastructure and organization into account. Consequently, it may be necessary/desirable to repeat tests in multiple geographic locations, on different servers and/or networks, to different printers or output devices, and so on.
System testing is a key milestone. System testing should be repeated for any new image, upgrade, major enhancement, or implementation.
2.B PeopleSoft Security testing
A part of SIT testing worth calling out separately is Security Testing, sometimes also referred to as compliance testing. Security testing validates the ability to control user access and prevent unauthorized user penetration into the system and the application itself. There are several aspects to consider in this area. Does the user have the correct authorizations to do their job? Is SOX compliance adhered to (Is access restricted to sensitive data, etc.)? Also as part of security testing will be the testing of workflows, and whether security is properly set up to adhere to the rules of workflow approvals - which is a massive job to do manually.
3. Performance/Volume Testing
PeopleSoft Performance/Volume testing, while focusing on many of the same areas as System testing (above), has different requirements in terms of the volume of data that must be generated and the way/timing of processing that data into the system. Performance/volume testing is hardware/network based and does not really have a business component to it. It doesn't focus AT ALL on whether things are working correctly but instead its focus is to ascertain whether the customer infrastructure supports the volume of data that will be pumped through the system on a regular, or time-based basis. On a regular basis, testing will want to check that both on-line and batch performance is acceptable. On a time-based basis, during open enrollment (benefits) for example, there will be a spike in the transaction volume that goes through the system because everyone, in a relatively short period of time (or defined time frame) will be on the system choosing their benefits (or registering for classes in Campus Solutions). Performance testing is important, and can be very important for some applications, or organizations.
4. User Acceptance Testing (UAT)
PeopleSoft User Acceptance Testing (UAT) is performed by a subset of key users with assistance from business application specialists. The acceptance test team should be largely composed of user representatives, with project team personnel operating only in a guidance and support role. In an implementation or upgrade this allows key users the opportunity to develop their skills in and knowledge of the new system functionality or navigation, and to verify the accuracy of the user procedures and online help to better support their end users. Each team member assigned to the test execution activity receives a test packet to provide guidance through the execution of the acceptance test. Key users may participate in test execution and should be empowered to "sign off" indicating user acceptance. Also, these UAT users are heavily involved at this stage in executing test plans to facilitate and expedite knowledge transfer and overall user acceptance of the system.
UAT testing is performed before final deployment to production, and is intended to both provide a final test of the system while building confidence in the system before end-users get their hands on the system.
The four types of PeopleSoft testing outlined above represents a solid testing methodology for implementations and full upgrades, as well as for situations where a company is adding additional modules and/or new features.
A final note. The term "regression testing" is often used similarly to system testing. (Regression testing is to repeat, or reuse, tests.) More properly, regression testing is focused on the reuse of existing test cases when bugs or fixes are applied, to make sure the "fix" did not break some other related functionality.
One of the greatest challenges - from a cost of ownership perspective - relates to testing around the updates supplied by Oracle in the form of patches/bundles/ or images. To ensure that updates to the system do not negatively affect the existing processing of data, customers are forced to perform regression testing.
Regression testing seeks to uncover new non-conformances after changes or updates have been made to a (copy of a) production system. Regression testing is normally first performed by the development team (to uncover any obvious issues with the newly introduced code) and then validated by a subset of key users or business analysts. Regression testing is especially important when the applications have been modified or customized, as the new code has not, or cannot, be validated by the vendor during the release process. Adding to this challenge, regression testing - especially when applying mandatory or regulatory updates to the system (such as tax updates) often must be performed in a time-limited basis, increasing the pressure on testing the accuracy of the new code.
Beacon has been implementing and upgrading PeopleSoft applications since 1992. These steps come from our methodology. 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.
CONCLUSION:
If you're moving to 9.2 (or already there) this is a good time to review and revisit your approach to PeopleSoft testing. The process of "changing" PeopleSoft is changing, creating new opportunities, and challenges to the old ways of doing things.
Questions or comments on this post, or on your PeopleSoft testing challenges and approaches are always of interest.
