Oracle Cloud Patch Testing: Are you having enough time to Fix Issues during Quarterly and Monthly patches?

All users and companies utilizing Oracle Cloud ERP, HCM, SCM, CX, CPQ and EPM are well aware that Oracle regularly releases quarterly or monthly patches to introduce new features, bug fixes, and enhancements. These updates are designed to continuously add value, improve business operations, and enhance the overall user experience.

Oracle currently deploys all changes to non-production instances first, providing customers with a two-week window to conduct regression testing and address any critical issues before the updates are rolled out to production environments.

We've spoken with many customers and found that they are currently approaching Oracle's Quarterly and Month patch regression testing in one of the following ways:

How companies are currently conducting their regression testing:

• Engaging internal business users to manually test their regression suite.
• Leveraging an in-house test automation framework to complete regression testing cycles.
• Purchasing licensed test automation tools and using in-house teams to build, maintain, and execute the regression test suite through automation.
• Outsourcing to vendors for manual script testing.
• Outsourcing to vendors who use automation to complete the regression testing cycle.

And following are the challenges they are facing:

• Inability to conduct full regression testing due to timeconsuming manual processes.
• Issues are identified late in the two-week window, leaving insufficient time to obtain fixes from Oracle or implement alternative solutions.
• Oracle updates often change functionality or UI, causing existing automation scripts to break, leading to time lost on script repairs.
• Vendors impose additional charges, cleverly included in the SOW, for updating test automation scripts when Oracle introduces changes.
• Poor documentation of test results, whether the scripts are tested manually or through automation.
• Higher Total Cost of Ownership (TCO) due to the need for tool licenses and the expenses involved in building, maintaining, and executing the scripts.
• Failing to complete a full round of executions within the first two days of the two-week cycle, resulting in delays in raising SRs, obtaining resolutions, retesting, or finding alternative solutions.

So how do we fix these challenges? and have more time to fix issues.

1. Test Automation (This is a given) :

If you are still testing the regressions manually, then I think you are way backward and it might take a lot of time to improve or optimize or transform your business in this fast evolving technology. Highly possible to lose to your competition, as everyone is adopting changes at fast rate to survive in the business.

So, make sure to have a test automation suite built for your regression scope, because testing them manually will need time of end users, whose valuable time can be utilizing in optimizing the business operations or spend their time in innovating the business operations or to be part of any transformational projects, or you have to hire additional manual testers just to test them, which can become expensive.

2. Candid testing process:

Even if you have full regression test automation suite ready, there is no guantee to reap it's benefits if there is no candid testing process, especially to test the Quarterly and Monthly patch testing of Oracle Cloud Applications, or even may be any other SaaS based Enterprise applications.

We have our own testing process especially for Quarterly and Patch testing for Oracle Cloud ERP, HCM, SCM, CX, CPQ, EPM and etc, you can reach out to me if you want to know more about it.

We have created a step by step process, which eleminates all the hurdles which might occur before the testing or during the testing or after the testing, and these hurdles are what generally cause delays in entire regression testing cycle.

Here are some steps on high level:

1. Have all information available before hand, which is required for regression testing.
2. Sanity check up of all issues which might arise during the patch testing, we created this list as we have vast experience doing this for years.
3. Keep the testing instance up to date and having it separate for testing purpose alone.
4. Update automation scripts.
5. Execuste scripts.
6. Reporting Issues and working with Internal Managed Services team or Customer to get them resolved.
7. Retesting on resolutions from Oracle.
8. Sending completion email with all test execution results, reports
9. Post checks.

You might think, this is not something new, but the depth is in the details and I am happy discuss if you have a need for your Oracle Cloud Apps related Quarterly and Monthly patch testing requriements.

this allows us to finish first round of execution of all the scritps for you in just 2 days of the two-week testing cycle.

3. Be smart to include following things in your SOW:

• When you choose a vendor who will conduct Oracle's Quarterly and Monthly regression testing through automation, make sure that you have the following things in your Statement of Work (SOW).
• The first round of executions should complete within the first 2 to 3 days, so that you will have enough time to raise Oracle SR's, get them fixed an retest them. Make sure the retesting is also part of the regression testing cycle.
• If any changes Introduced by Oracle, your vendor should not charge you additional fee to fix the regression suite unless the change is so major that more than 30% to 40% of your scripts needs fixing.
• Always have some additional number of scripts (say 25 to 30 ) in scope to what you already have in scope, so that in future if you have any additional features implemented, they can automate them as well for free.
• No additional charges for replacing existing automation scripts, because you might have enchanced your business processes and needs a different flow to what was there earlier.

If you'd like to learn how to craft an effective SOW for your test automation vendor, feel free to contact me. What I’ve covered here is just a portion of the details; there’s much more to consider.

4. Choose a vendor who is doing this for years and having at least 15 to 20 customers for this activity.

I highly recommend to go for an outside vendor for the following reasons:

If you hire inhouse test automation team especially for Oracle Cloud applications testing, these are the following things you will have to bear and is not worthy in my perspective:

Initial time to build Test automation framework: Building test automation frameworks for SaaS enterprise applications is completely a differnet ball game than to create for custom web applications. In my 19 years of experience I have built 3 such humungous test automation frameworks in 3 differnt companies specifically for Oracle Cloud ERP, HCM, SCM, CX and etc.. every time i built a new framework I had redesigned the entire archicture for the automation framework and have seen improvements and much better benefits.

I’ve developed many test automation frameworks for various use cases. If you want to understand what should be included in a test automation framework, feel free to contact me. I’ll do my best to share my experience and insights.

So if you build your own test automation framework, I would say a min of 4 to 5 months will go into it, and it will still need continuous enhancements.

But for the vendors who have been working on this for more years, their test automation framework would have undergone a lot of rounds of enhancements and optimization and it will be ready to use for them and reduce a lot of time there.

Cost shared across customers: Along with the humongous experience and ready to use automation framework or tool and they are also working with multiple customers, because of which even if they fix a reusable script or library or introduce enhancements or bug fixes, they get to do it for all their customers in the space or Oracle Cloud ERP, HCM, SCM, CX and etc.

This way the cost is spread across multiple customers and they are able to give you services at a very less cost.

One fix for all: As they are working multiple customers and functionality is similar across customers, even if there is some change introduced by Oracle, their automation experts will be on toes to fix them as early as possible as that is their main responsiblity to solve for all at once, otherwise it will cost a lot for them and also can lose the business. So, once they give a fix, it is given to all customers. This speeds up the fixes and maintenance even during the Quarterly and Monthly patch testing.

They must complete first round of execution in first 2 to 3 days: The entire vendor's team will be focusing on finishing the first round of execution in first 2 to 3 days to leave ample time for customers to analyze on the issues identified. Otherwise it can impact their business deals, it is not the same with your inhouse team, as this may not be their main goal.

They constantly work on improving the quality and reducing the overall script executions time by enhancing the tool or test automation framework or internal processes otherwise they know that they will be out of business to competition. Otherwise they have to deploy more resources and increase their costs, which the vendor does not want to do. So vendor will always look at reducing their internal costs for which they must enhance their assets, toolls and etc, which indirectly benefits the customers in both time and money.

Vendor will always look at enhancing their assets, tools and delivery which indirectly results in customer benefits like improved quality, faster delivery and lesser cost.

Fixes or Enhancements are not charged additionally: When you chosoe a vendor for your test automation services, they constantly spend time to enhance the capabilities and features, and you will get all this at no additional cost. Same as how Oracle is pushing changes on Quarterly and Monthly patches to add value to their customers.

There are many more reasons why we need to outsource to vendors or experts instead of doing it inhouse, those are not in scope to the current article. I will try to compile that information may be in a different article, say like "Should you purchase a Test automation tool or get Test Automation services from vendors?"

Now, if you liked the content, request to like it and share it on your feed so that more people can get benefited. And, if you did not like the content, feel free to share your feedback in form of comments, I will take the feedback and work on it.

Also, let me know what kind of topics you want me to write, I will try my best to write.