Customer Upgrade Testing

Overview

Customers should actively test new versions applied to non-production environments before a scheduled production upgrade. At minimum, customers should test the lifecycle of a transaction, with the typical actions that sales users perform. These may include but are not limited to: start transaction, new configuration, reconfigure existing configuration, parts search, discounting, printing, revisions, and approvals. Integration points should also be tested. Reviewing the What's New is highly recommended as this practice may indicate additional focus areas for testing.

Customers should also test any customizations made on the environment, especially JavaScript and unsupported integrations. Note that custom JavaScript is the most frequent cause of post-upgrade issues. Custom JavaScript and unsupported integrations are not supported by Oracle Support or Development. In particular, note that an upgrade may introduce changes to the DOM, which could impact use of customer JavaScript and CSS.

While Oracle CPQ does not endorse or guarantee the use of JavaScript customizations, we recognize that some customers have extended Oracle CPQ to support critical use cases. JavaScript API ("CPQJS") includes methods for accessing attributes, actions, and other elements on the JET Configuration and JET Transaction UIs. Customers should consider carefully the relative benefits of JavaScript customizations in light of the associated risks. Customizations may conflict with new Oracle CPQ platform features, data may be corrupted or lost, maintenance and support may be difficult, cross-browser support must be verified, performance may be impaired, and testing is required for each upgrade.

Oracle CPQ does extensive testing as part of the release cycle. Therefore your testing plan efforts should focus on testing customer-specific use cases rather than general tasks such as adding a configuration attribute.

Update Early Testing and Cohort Schedule

Customers are encouraged to take advantage of the Early Test periods in their 25B Update Cohort. This provides time for you to update one or more pre-Production environments to test customizations and use cases and make any necessary adjustments. The following table summarizes the Oracle CPQ Update 25B schedule. If you are uncertain which Update Cohort you are in, please submit a Service Request (SR) My Oracle Support.

Cohort	Early Test Updates	Pre-Production Updates	Production Updates
A	April 4 and 5	May 2 and 3	May 16 and 17
B	April 4 and 5 May 2 and 3	June 6 and 7	June 20 and 21
C	May 2 and 3 June 6 and 7	July 4 and 5	July 18 and 19

Oracle CPQ follows the Oracle SaaS Cohort Update Policy and Schedule. Quarterly Updates cannot be skipped. You need to integrate your Update schedule into your business and project plans. Customers must opt-in to Early Test by submitting a SR on My Oracle Support. You may elect to permanently opt-in to Early Test but must keep the same Early Test sites and cadence to do so.

Customers may request to have a few Pre-Production environments upgraded along with the Production environment on the standard Production schedule by submitting a SR on My Oracle Support. You may request to have the same sites upgraded along with your Production environment permanently to avoid having to submit SRs every quarter.

Issues after Upgrade

If a customer experiences issues after the upgrade, there are two different processes depending on if the upgrade is a non-production or production upgrade.

Issues after Non-Production Upgrade

• Log a Service Request (SR) through My Oracle Support.

• The Service Request will be picked up by Customer Support, and assigned to the Point of Contact (POC).

• The Service Request is worked as a standard Customer Support Service Request.

Issues after Production Upgrade

• In most cases, production upgrades go smoothly and the Upgrade Service Request is closed once the upgrade completes.

• The customer is instructed to open a "Severity 1" Service Request in the event that there is a critical issue after the production upgrade that was not identified after the non-production upgrade. Critical issues after upgrade would be considered production site down, 100% of users cannot quote, or other revenue impacting business critical issues.

• Once the "Severity 1" Service Request is created, the on-call team is notified.

• On-call team member(s) will work the Service Request towards resolution.

• On-call team member will then reach out to Oracle Upgrade Specialist who performed the post upgrade validation if needed.

Related Topics

See Also