When I’ve asked for a show of hands for who uses PeopleSoft Update Manager (PUM), I usually see a majority of hands raised. The most recent update from Oracle shows that roughly 72% of all PeopleSoft customers are on release 9.2, and most have used PUM. Customers whom I’ve talked to have found that PUM simplified the update process and lowered their overall cost. However, one area that these customers have complained about is the amount of time it takes to test.

There is no getting around testing after an update. I’ve heard of organizations that only test those areas that were directly touched by an update, skipping the rest. While the areas not touched are likely 100% good, I am not comfortable with essentially betting my job/bonus/judgment that the system is ready for running the business without performing a comprehensive system test.

When we (Sierra-Cedar) introduce Oracle’s PeopleSoft Test Framework (PTF) to our clients as a way to save time while increasing confidence in their updated system, we find them interested but skeptical. Now it is true that the payback happens after more than one upgrade, and it’s also true that your investment of time in developing/updating custom PTF scripts may be needed every time a PUM Image is applied. You can expect that it will take 2–3 update cycles to hit the breakeven point, i.e., the savings from automating your testing, reducing test labor, and test duration are more than your initial effort that created the scripts. It is also true that once a test script is written for your environment, it takes very little effort to maintain it, run it with each update cycle, and verify the results. The intangible value is the peace of mind and confidence you’ll have in knowing that all the tests were run, all of them produced the expected results, and you have good documentation of the results of all the testing.

Here’s a recommendation we share with clients that is quite valuable but may not be intuitive: when you plan to deploy PTF, designate a separate project for creating the test strategy, test cycles, and PTF script development. When PTF is initially developed, it takes focus and attention from both functional and technical staff. The time and skill that you need will compete during a PeopleSoft update project. Schedule the PTF separately to give yourself the time to focus on creating a plan for what you want to accomplish, and then execute your plan. Plan the deployment in stages. Take the delivered test scripts and modify them, if necessary, for your environment. After this success, go on to the next phase and build more complex test scripts. PTF is very robust and supports variables, scripts that can run other scripts, and much more.

The value of PTF is the shortening of the overall time required to complete an update as a result of automating testing. PUM has automated many steps and processes that previously took many hours, and sometimes days, to complete. PTF does the same; it does what previously took many people and many days to complete and also documents what it did.

Simply put, PTF shortens the overall time required to complete an update. This is the result of automating the testing process. PUM has automated many steps and processes that previously took many hours, and sometimes days, to complete. PTF accomplishes the same thing: what previously took many people, many days, and many documents to complete is completed with fewer people, less time, and consistent documentation.

When I say that PUM & PTF go together like “Copy & Paste,” it means that when you use PUM, you really should deploy the “other half” of the update process and automate your testing. Thorough regression testing is the only way to reduce the risk of failure after a PeopleSoft update. Remember that PTF comes included with your PeopleSoft License. It pays for itself in 2–3 update cycles, and best of all, it provides you with a higher level of confidence that the system will perform as expected.