The key component of a Technical Upgrade is CEMLIs retrofit. Automation plays a key role in the following areas:
- Automated Identification of Upgrade areas
- Automated Remediation of CEMLIs retrofit
- Automated Testing of the Upgrade
In this section, we will examine the myths and realities of leveraging automation.
Automated Identification
With over two decades of upgrade experiences, like any service provider, AppsTek came up with an Upgrade Assessment tool for automated identification.
- Our tool covers custom alerts, applications, database objects, flex fields, forms, form messages, forms personalization’s, FSGs, lookups, menus, OAF objects, profiles, request sets, responsibilities, triggers, value sets, and workflows
- Ensures thorough scanning of the current environment, analyzes the usage and obsolescence, and produces reports that help in comprehensive and detailed planning of all the components involved in the upgrade
- The tool automatically generates a project plan to track the progress of the CEMLIs, which can be integrated into the overall upgrade project plan
From our experience, our tool performed with an accuracy of 99% in identifying the objects and remediation locations.
Automated Remediation
Possible scenarios for identification and remediation are tabulated below:
- Manual Identification and Manual Remediation, which is outdated.
- Manual Identification and Automated Remediation, which may not be a valid/ feasible approach for the broad CEMLIs/ RICE-Ws remediation. It may be useful for global hard coding updates.
- Automated Identification and Manual Remediation. This gives
- Opportunity for optimization
- Detailed visibility into the Component for future maintenance
- Opportunity to enhance inline / offline documentation
Our tool along with standard Oracle upgrade tools cover 80-90% of the objects with automated remediation.
The remaining 10-20% of the objects, viz. Interfaces, Reports, Workflows require manual intervention over and above the assistance provided by the tool. This manual intervention is required to ensure maintainability of the source code, updates to functional and technical documentation.
- Automated Identification and Automated Remediation: Some may claim 100% automated remediation, but you lose control and visibility. In this black-box approach, even exception-based review of few CEMLIs may result in more effort than the direct manual remediation and optimization. Interfaces, Workflows and Reports need detailed manual remediation and oversight to get it first time right, as there are more moving parts in terms of
- application versions of Oracle EBS and 3rd party applications
- enhanced user interface and report layouts
- some reports are now part of the standard Oracle EBS
- process and activity monitoring changes in the workflows
We strongly recommend a grey-box approach to the remediation of Interfaces, Reports and Workflows.
Automated Testing
Conventional wisdom suggests that test automation suites are developed on stable application environments. Stability and agility are the trade-offs every organization faces, and it is the same in the connect of Oracle EBS. In-sprint and lagging sprint automation advocates recommend factory approach automation.
Organizations which leveraged manual testing for Oracle ERP solutions, were in a transitional need of automation, to cater to the high number of regression opportunities during smoke/ regression testing for patches, functional testing of major upgrade, implementation of new modules/ business processes. Benefits of automated testing include ROI, Running tests 24×7, Reusability, Error Free, Test Coverage, etc.
If the regression opportunities justify the investment in the development of test automation suite, you might have already got one and your environment is on the latest application environment/ patch. It is important to ensure that you are on the latest source environment patch prior to the onset of the upgrade. Key reasons why you are not up to date with your EBS patch schedule could be:
- EBS customizations have not followed the Oracle standards and so will need to be modified after a patch is applied.
- Migrating customizations across environments can be time consuming and error prone, especially if the point above is true.
- EBS 12.2.x runs on WebLogic and you may not have the sufficient WebLogic expertise on your team.
- Production-outage time associated with an upgrade cannot be mitigated because of a lack of sufficient test and pre-prod environments.
When you embrace test automation, for your BAU operations of Oracle EBS Support and Maintenance, it is important to:
- Invest in end-to-end Oracle EBS test automation
- Select on Oracle EBS test automation tool that can test cross-application workflows
- Incorporate your EBS releases into your DevOps pipeline
Automated Test Tools for Oracle EBS fall into one of the following categories:
- OEM – Oracle Application Testing Suite and variants based on OATS
- Commercial Test Automation Tools – E.g., TestComplete from SmartBear, UFT, SlikTest from Microfocus, QSome from Audacix, Certify from WorkSoft, RFT from IBM, OpKey, etc.
- Service Provider created test tools – These are based on OEM, Open Source, or Commercial Test Automation Tools based utilities – Tools and Scripts Libraries and rarely home-grown tool. E.g., TestArchitect from LogiGear, Panaya, etc.
- Open-Source Test Automation Tools – E.g., Selenium, Watir, Cucumber, Sikuli, etc.
Any Upgrade Service Provider must be honest with the customer in terms of the level of applicability of techniques and tactics during a Technical Upgrade. Technical Upgrade does not require full functional testing. It also provides an opportunity to revisit the code of CEMLIs in a grey box test scenario. When there is an application upgrade, interoperability with the 3rd party applications requires rigorous manual testing.
Myths in Technical Upgrade Test automation include
- 100% automated testing
- Leverage of the same test scripts in different deployment scenarios, OEM application versions and 3rd party application versions
- Needs end-to-end functional testing
- Vendor Lock-in with as-a-Service offering
- One tool for all the applications in your landscape
- Script-less test automation which some feel as a snake oil of automation
Realities in Technical Upgrade Testing includes the following:
- Conformance with Oracle Global standards and compliance for ensuring quality at the source and ease of ongoing maintenance during the retrofit which automated testing will never catch
- Reuse of available business process documentation, test scenarios and scripts, automated test suite and updating them to 12.2.9 for reduced risk-based testing based on the scope of CEMLIs and affected components
- Development of new test scenarios and scripts based on infrastructure and technical upgrade impact on the Oracle EBS 12.2.9 environment and functionality.
- Planning of test strategy, test data and test environment management are integral to the upgrade plan
- Participation of key users, 3rd party application providers in difference document studies (schemas, file formats, UI, and functionality) and designs early in the process (shift left)
- Sharing of Unit and System Integration Test (SIT) scripts for UAT execution
- Enhancement of the existing automated test suite to include risk based prioritized scenarios during the upgrade and the post-production support
Conclusion
- Automation is necessary but not sufficient.
- Key components of Technical upgrade viz., re-platforming and CEMLIs retrofit do not require end-to-end functional testing.
- Many times, a technical upgrade involves re-platforming and most likely your automation test suite does not have automation scripts as re-platforming is not a frequent event.
- User experience is determined by the usability, performance, and security. Test automation scripts developed for the source environments would need to be tweaked with the target environment configurations, parameters, etc. If it brings OCI into the mix, the non-functional testing is all together a different challenge. Web Application Firewalls, WebLogic Server Fusion Middleware platform in 12.2.x may demand re-development of the scans and scripts.
- CEML objects are remediated either automatically or manually. Automated Identification is key during the Technical Upgrade. Their automated identification to the extent of 99% suggests that remediation is happening like test-driven-development, which ensure quality at the source.
- Interfaces, Workflows and Reports have unique characteristics in terms of many moving parts, technology upgrade – process and user interface, obsolete objects, etc. It is almost certain that whatever the test automation scripts you have would need to be updated in the target environment which is as good as creating a new script. Follow grey-box and collaborative remediation with automation where possible.
- Test effort tapers progressively through the iterations leading into the UAT.
- Enhance baseline BAU Test Suite for use after the upgrade to a stable target environment.
- Update MD050, MD070, CV120/MD120, TE040, etc. documents during the upgrade as applicable.
One tool may not automate all the applications and 100% of any application. Do not fall prey to the false promises.
