Stop Retrofitting and Analyzing Every Customization!

When applying maintenance, we must retrofit every customization. And we will have to continue analyzing and retrofitting as long as we have customizations. The process involves running Compare Reports to identify changes, analyzing customizations, and copying/pasting our old solutions into Oracle's new code base. Occasionally, we must alter a customization to account for Oracle's changes. My point is that we must touch every single customization identified in a Compare Report. The alternative is modern isolation strategies, such as  Page and Field Configurator, Event Mapping, and Drop Zones. We call these isolated customizations because changes are isolated from Oracle's delivered code base. They don't appear in Compare Reports. But should they still be analyzed? Do they require retrofits? Do they break during maintenance?

Without a Compare Report, how do you find isolated customizations? Do you need to find them? We have been discussing this lack of transparency since Event Mapping was released in PeopleTools 8.55. In fact, we've written SQL to help you locate code that includes Event Mapping that was touched by maintenance. But do we need to review every isolated customization? Here is an example. In 2016, I used Event Mapping to change the appearance of the Addresses Page. Notice the iconography next to the Home and Mailing Address in the following screenshot:

I haven't touched this isolated customization in 7 years. That is 7 years and possibly 21 "Get Currents" without a single care for this Isolated Customization! And then, I applied HCM PUM 46. Here is the result:

I've Waited 7 years for this to happen! Shouldn't a compare report have caught this? No. That is the point of an isolated customization. Our code is isolated from Oracle's code. Therefore, there is no Compare Report. But as you can see, sometimes our code still breaks after maintenance.

So what is the solution? How do we identify isolated customizations that broke while applying maintenance? Regression Tests. The solution to this challenge is the PTF Regression Test. Each time you create an Event Mapping, Drop Zone, or Page and Field Configurator solution, you should create a corresponding PTF regression test to prove your solution still works. A PTF Regression Test would have caught the error message and instantly failed the test. I would then analyze and retrofit just this one broken solution, not every single system change.

Compare Reports for Event Mapping, Drop Zones, and Page and Field Configurator? Do you really need them? Wouldn't a proper Regression Testing strategy save you hours, even days, of analysis by avoiding report reviews?

At JSMpros, we teach developers and business analysts how to create PTF Regression Tests through our two-day PeopleSoft Test Framework course. Find out when we are offering it next, or learn at your own pace through on-demand!