An Insight into Oracle Fusion Patching and Testing Readiness

Listen on the go!

oracle patch updateTraditionally in the Software Development Life Cycle (SDLC), a patch is a fix, a quick repair job, or a piece of programming designed to resolve functionality issues, improve security, and add new features. Throughout its lifetime, the software gets frequent errors called bugs which produce unexpected results, and a patch is an immediate fix to those problems. 

Applying modifications to the Oracle Fusion Applications environment is called Oracle Patching. We need patching to solve security vulnerabilities, improve performance, fix bugs, and add new features. Continuous patch application minimizes incidents where bugs are encountered. It ensures the instance of Oracle Fusion Applications is performing efficiently and thus improves security. 

Oracle Fusion Patch Categories 

Oracle Fusion application patches fall under two different categories as mentioned below.  Oracle Fusion Patch Categories

 Oracle Fusion Patching Tools 

Based on the patching categories and patch types there are various tools to apply. Below is the table that describes, the patch category, patch types, and tools applicable. 

Technical Patches  Tools 
Technical One-Off  OPatch 
Critical Patch Updates (CPU)  OPatch 
Technical Patch Bundle (P4FA)  FASPOT under P4FA section 
Functional Patches  Tools 
Functional One-Off Patch  As described in the Apply One-Off Patches section – Fusion Applications Patch Manager”   
Functional Patch Bundle (BP)  As described in the Apply a Functional Patch Bundle section – “Fusion Applications Patch Manager “ 
Aggregated One-Off  As described in the Apply a Functional Patch Bundle section— “Fusion Applications Patch Manager”   


OPatch: It is an Oracle utility tool that helps organizations with the process of applying patches to Oracle’s software and rolling back.  

FASPOT: FASPOT is used to arrange the installation of the P4FA bundle patches. It has certain guided preparation steps to follow while applying bundle patches. 

FASPOT applies the patches in the below listed categories: 

  • Fusion Middleware Components (including ODI, atgpf, oracle common, webtier, SOA, BI, WebCenter, ECM, SES, wls) 
  • Identity and Access Management (including OHS and OID) 

The installation of RDBMS patches is not within the scope of FASPOT and must be installed manually by Database Administrators (DBAs).  

Oracle Fusion Applications Patch Manager (Patch Manager)- The basic function of a Patch Manager is to apply functional standard patches, and bundle patches. It can also validate whether patches can be applied and generate patching reports or not. Patch Manager provides a command-line interface to systemize its patching functions.  

Skill, Key Roles, and Expertise Needed to apply the Oracle Patches 

To apply Oracle fusion functional or technical patches, certain skill set and knowledge is required as mentioned in the below table. 

Roles/skill   Technical knowledge areas 
A Fusion Applications administrator  Oracle Fusion Application installation(s) knowledge 
A Database administrator  WebLogic and SOA familiarity 
An Identity Management (IDM) expert  Database knowledge 
  Identity Management knowledge 
  Relevant operating system knowledge (Linux, etc.) 


Key activities: when planning a patching activity for Oracle Fusion Applications environment 

  • Patch Planning 
  • Patching Tools are set 
  • System Backup planning 
  • Impact Analysis of the patches 
  • Patch Test Planning. 

 Summary describing when to apply the patches  

Type  One-Offs  Aggregated one offs (AOO)  CPU  Patch Bundles 
Technical  Apply only when there is critical issue, else wait for patch bundle release  Not applicable  Upon release apply Immediately  Ideally apply every month, and less frequently than every month is not recommended. 
Functional  Apply only when there is critical issue, else wait for patch bundle release  Apply only when project timelines impacted else wait for update bundle  Not Applicable  Apply Monthly upon release or choose alternates based on the requirements 


 Overview of Oracle Patch releases 

 For every quarter, Oracle releases a quarterly patch update cadence through the Oracle applications cloud console. Here the information on software and hardware patch updates are specified and are applicable for the environments mentioned below. 

  • New Features/Functions 
  • BUG Fixes 
  • Provide Infrastructure updates 

Monthly Updates from Oracle: Optional 

Oracle notifies all its partners service admins about the updates included in each patch. For minor patch releases, Oracle typically provides a one-week advance notification before patching the test environment, and for major update releases, Oracle provides a two-month advance notification. 

A document with the detailed information is shared with the admin informing about the released patches and the same get uploaded on the Oracle Cloud Release Readiness website. The information on the website includes announcements, new features, changes in functional behaviour, and bug fixes. 

Website link:

Quarterly Updates: Mandatory 

In a calendar year, there will be four feature/function updates to notify partners about the schedule of the quarterly update period. 

Quarterly updates may include: 

  • New and enhanced features/ functions 
  • National Language Support (NLS) updates applicable for all installed language packs 
  • Fixes for all reported issues linked with Oracle Cloud Applications 
  • Fixes for all reported issues linked with Oracle Transactional Business Intelligence (OTBI) and Oracle Fusion Middleware. Sometimes the middleware updates are even referred to as P4FA updates 

What is Opt-In and Opt-in Expiration? 

Opt-In: Based on the functionality and features, the release of the quarterly patch has two options – Enabled and Disabled.  

Enabled means the availability of the patch release to the end-user immediately once oracle pushes the update, without any human intervene. Disabled means the client must take step by step action to make the patch release available to them. 

Opt-In Expiration: Feature which automatically makes the Disabled options of Opt-in Enabled for the future patch release updates. The disabled features of previous releases get automatically enabled in the oracle cloud application instance.

Managing Oracle Cloud Fusion Patching with Cigniti’s Best Practices and Guidelines  

Most enterprise organizations are adopting cloud-based IT operations/administration and currently the market is in the transformation phase. Oracle fusion cloud is one of the top ERP solutions for big and mid-size enterprises. 

As mentioned above, every quarter Oracle provides software and hardware updates for its partner Oracle cloud environments through patches. 

We know, patching is the process to modify the Oracle Cloud Applications comprising new functionality, UI changes, customer enhancement requests, and bug fixes. As the updates are mandatory and inevitable, testing must be done to ensure whether all the enhanced functionalities are working according to the business operations of the organization or not. Testing is even needed to know, whether the changes have not impacted their BAU. 

So, enterprise clients should complete testing, analyze the results, and raise issues with Oracle within a limited interval of time. Oracle opens the testing window for approx. 2 weeks only. Testing of the quarterly patch is a joint effort by IT/DEV, QA & BA’s, and it needs perfect coordination. 

Below are a few fundamental requirements before testing begins. 

  • Quarterly Release Schedule: knowing the patch release date to plan for the quarterly patch testing 
  • What’s New: Regular check of the Oracle Cloud Readiness website to understand the updates on new features, capabilities, etc. So, one should timely check on the features and remain updated and identify the forthcoming updates, which also helps create the test cases. 
  • Opt-In Expiration: One should be aware of the features falling under the “Opt-In Expiration” to plan for testing in the next quarterly update.
  • Test Case Readiness
    • Regression: Common test cases with every quarterly patch 
    • Upgrade Specific: New Test cases specific to the quarterly patch, upcoming features, and capabilities in the quarterly patch 
    • Opt-In Expiration: Test cases for features automatically migrated to production from the previous release 
  • Quarterly Patch Application: Firstly, the Quarterly patch gets implemented in the Non-Production instance, and then it is done to the Production instance. You only have a two-week window to execute all the test cases before the patch gets applied to the PROD instance. And before the patch gets applied to PROD, all the executed test cases must PASS. In case of failure, a user should raise an Oracle SR and immediately put the PROD patch application on hold. 

Cigniti has a unique way of approaching these testing challenges of the oracle fusion cloud. Below are the best practices that we follow to meet the oracle fusion patch testing schedule. 

  • Create a patch tracking sheet 
  • Analyze the patch impact on the applications and create a test plan accordingly. 
  • Types of patches to plan and apply 
  • Impact assessment of the patches 
  • Based on the quarterly patching schedule, prepare the test cases well in advance.  
  • Follow the Cigniti checklist for fusion cloud testing 

Cigniti Patch Testing Check List  

Action Items  Period/Time  Ownership  Preparation/comments 
Analyze Quarterly Updates  Available before 2 months of the release  QA Team  Follow the below link to review – 

Create Test Plan  Week1  QA Team  Regression, patching specific test cases, and Opt in expiration scenario test cases 

  • New Features
  • Opt-in Expiration Features 
  • Test Plan 
Week2  QA Team  Review in detail 
Present the patching test coverage/plan and get it approved  Week2  Client BA’s  Client BA’s to approve the test plan 
Create Manual Test cases  Week2 and week3  QA Team  Manual test cases to be enhanced or new manual test cases should be authored 
Apply Patch in Test Environment  Based on the release date  Oracle  Oracle shares the instance downtime details generally two weeks prior to the quarterly patch application date 
Manual and Automation Regression testing  Execute in 2 weeks window  QA Team  Test and update results with the stakeholders 
Testing sign off/Review  Once after the execution is done  Client BA’s  In case the testing fails, raise an SR with Oracle to stop the quarterly patch from getting applied in the PROD instance 
Apply Patch in Production  Based on the release date  Oracle  Oracle shares the instance downtime details generally two weeks prior to the quarterly patch application date 
Production sanity checks  After applying the patch in production  Dev Team/Client BA’s  Dev to do the sanity check in prod or the client BA’s 


Need help? Schedule a discussion with our ERP Testing experts to get more insights into oracle fusion patching and testing readiness.                                                                                                                                                                 


  • Timothy Aegoori

    Timothy Aegoori has been a Lead Business Analyst associated with Cigniti Technologies for the past 6 years, representing the ERP Centre of Excellence team, and has 12 years of strong consulting experience in ERP packages like Oracle, MS Dynamics, SAP, Infor, etc. His expertise includes ERP advisory, solutioning, pre-sales, CoE establishment, discoveries, and assessments in all types of ERP projects and different domains across industry verticals.

    View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *