Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« Looking for the First Step on the Cloud Adoption Path?- Cloud Based QA Environment | Main | Testing for cloud security- What is the infrastructure focus of QA teams (Part 1/3) »

What to expect from Test Automation of Oracle Applications?

I just finished putting together a response for a client trying to understand the value of automation during testing of Oracle Applications. Essentially the client was trying to evaluate whether automation is a worthwhile investment and evaluate the returns expected. I figured this topic to be a subject of much discussion, given widespread implementation of Oracle Applications.

Here are a few points one might want to keep in mind while considering functional automation in their strategy to test the implementation of your Oracle Applications

  • Level of Customization: In a plain vanilla implementation more than 85% of the testing can be automated. As the customization of the Oracle packages increases, the extent to which automation can and should be implemented drops significantly. Customizations are in the form of RICEF components - Reports, Interfaces, Configurations, Extensions and Forms. As such they are not natural candidates for automation and limit automation feasibility.

  • Maintenance of test scripts: As part of application/ IT maintenance, constant changes are made to the customizations. Attempts to keep automation suites up to date can prove expensive than initially thought to be. The size of the maintenance test case repository is also decided by the cost of maintaining the repository itself. At times it may make financial sense to limit the size of the automation suite.
  • Test Data: One of the prime reasons to consider automation of packaged applications is the presence of "Global Processes" which are tested across multiple countries/entities. Automation test scripts created once for global processes are executed for several countries. Availability of test data specific to each country eventually determines the automation coverage.
  • Test types for automation: Automation of System Testing type test cases are easier but lesser return on investment when compared to automation of System Integration type flows, which are uneconomical but provide higher returns.
  • Extent of Reuse: It helps if the automation team is aware of and can identify country specific deviations or rather the common elements across countries. This information can lead to increased reuse during automation of country specific test scenarios.
  • Granularity of test cases: Test cases written to cover business processes are more effective to automate than those written at a more granular level. It is so not only because they simulate real life scenarios better but also because they help enhance test coverage

Paying close attention to the above mentioned points will definitely help you gauge what to expect from your automation endeavors. 

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Infosys on Twitter