SaaS Application Patching and Upgrade Testing: Preparing for Readiness is the Key
Patching and upgrade testing becomes an important aspect as any major/minor issue will impact the business functions at large.
Join the DZone community and get the full member experience.
Join For FreeCloud technologies have revolutionized the software application development and delivery process. As more and more companies are realizing the benefits of reduced infrastructure costs, automated production deployments, and increased security in the cloud, commercial off-the-shelf products are on the rise to provide business-ready solutions to the customer. The products that were traditionally developed, bundled, and deployed on the premises of the customer or hosted in-house to provide the applications and services are on the transformation path to the cloud. These Prem applications always have challenges as the customers are on different versions of the product, on different infrastructure versions, and specific customizations for the customer need more maintenance; scaling the applications based on the usage is often more a reactive approach than a proactive approach.
Software-as-a-service (SaaS) applications alleviate the vendor selling the product from the above challenges as all its customers are on the same version of the cloud infrastructure through patches and upgrades, which the customers can’t avoid. The ability to scale up or down depending on the customer's requests is proactive. Also, it provides enhanced customer experience by releasing new features regularly without the customers having to wait long for their favorite features.
The SaaS application is constantly updated by the vendor with regular patches, upgrades, and new features on daily, weekly, monthly, and Quarterly periods. Patching is the process of modifying the Cloud Applications comprising new functionality, UI changes, customer enhancement requests, and bug fixes. Customizations are often not encouraged. This constant change in the application puts the customers with the ownership of making sure the business process is still intact. There is no negative impact within a short span of time; mainly, a couple of weeks is given to the customer to test these patches in a non-production environment, new features, and any infrastructure upgrade on the vendor cloud side without any exception unless a major feature is not working.
Patch testing becomes an important aspect as any major/minor issue will impact the business functions at large, e.g., Corporate Finance, HR Systems, etc. Below are a few fundamental requirements needed before testing begins.
| Quarterly Release Schedule | Vendor releases the patch release dates well in advance for major patches; it is useful to plan for the upcoming patch testing ahead. |
| What’s New | Regularly check the vendor 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 | We should be aware of the features falling under the “Opt-In Expiration” to plan for testing in the next quarterly update. |
| Patch Test Readiness | |
|---|---|
Functional and Regression Testing |
Test Cases covering the existing standard application Workflow as per the business standard operating procedures, Integrations with other systems that are Cloud or On-prem and legacy systems, and Reports for every patch should be well documented in collaboration with Business users, product owners, developers, and QA teams. A clean Test environment with setups, configurations close production environment, and user-level access and privileges mimicking business users should be ready well before the patch is applied by the vendor. Automation Scripts execution for these test cases will help identify issues sooner to revert back to the vendor for resolution. |
| Upgrade Specific | New Test cases specific to the patches, infra upgrades at the cloud vendor, upcoming features, and capabilities should be well documented. Collaboration with business users on the new features is extremely important as they may be impacting the current workflow and UI changes; all the teams should analyze and do an impact analysis. This is should be tested both by the Users and the QA team. |
| Opt-In Expiration | Test cases for features automatically migrated to production from the previous release. |
| Patch Application | The patch gets implemented in the Non-Production instance, and then it is done in the Production instance. Customers 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. |
A checklist helps all the stakeholders to know their roles, an illustration of how the Oracle Fusion Cloud Quarterly patching is done is illustrated below.
| Patch Testing CHECKLIST | ||||
|---|---|---|---|---|
| S. No | Action Items | Period/Time | Ownership | Preparation/Comments |
| 1 | Analyze Quarterly Updates/New features | Available before two months of the release. | PO/DEV/QA Team | Follow the link to review. |
| 2 | Review with Development /Product Owners/Business users | 1 Week before Patch | QA Team | Review in detail:
|
| 3 | Create/Update Test Plan, Test Data |
1 Week before the Patch |
QA Team | Regression, patching specific test cases, and Opt-in expiration scenario test cases. |
| 4 | Apply Patch in Test Environment | Based on the release date. | Oracle | Oracle shares the instance downtime details generally two weeks before the quarterly patch application date. |
| 5 | Manual and Automation Regression Testing |
Execute in 2 weeks window. |
QA Team | Test and update results with the business users. |
| 6 | Testing sign-off/Review with DEV/PO/Business users |
Immediately after the execution is done by module. |
QA Team | In case the testing fails, raise an SR with Oracle to stop the quarterly patch from getting applied in the PROD instance. |
| 7 | 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. |
| 8 | Production sanity checks |
After applying the patch in production. |
Business User | Business Users do the sanity check in production after an upgrade. |
Often the SaaS applications have many functionalities and come bundled with loads of features; it is imperative as the customer using the product to make sure what we absolutely need for our business is identified and tested thoroughly within the short span of time given.
Opinions expressed by DZone contributors are their own.
Comments