By: Krishnan Venkatraman, Associate Director - Package Implementation

In the rapidly evolving landscape of technology, businesses are under constant pressure to deliver products quickly while adapting seamlessly to changes and requests. Quality testing, particularly with automation across various technologies and platforms is paramount, in this scenario.

Traditional software testing processes are often cumbersome, time-consuming, and prone to errors. These problems hinder businesses from fully realizing the potential of their Oracle deployments. Testing-as-a-Service (TaaS), however, enables a flexible, scalable, and cost-effective solution to meet the challenges of traditional testing, and provides a revolutionary approach to software quality assurance.

LTIMindtree’s framework for TaaS facilitates faster, accurate testing, and test automation maintenance. With pre-built features and scenarios, the framework eliminates the need for code changes or software installations. With a comprehensive suite of assurance and compliance services designed exclusively for Oracle test environments, the platform provides end-to-end testing for Oracle Cloud applications powered by various in-house tools and partner tools.

What makes our Framework exceptional?

Scripts can be executed in different browsers, instances, and regions/locations/organizational units without script modifications. To simplify script maintenance and changes, we employ function libraries for common/utility features and application-specific functions. We maintain a Page Object Model (POM) for forms and web elements, and reports are stored and derived at multiple levels, with the option to archive previous reports based on requirements. We continue to enhance our framework by integrating more features with tools like Jira Test Management.

How do scripts run in various environments?

Config.properties file fetches browser and location details during script execution. Separate config.properties files are maintained for each instance (UAT, PreProduction, and Production). Arguments are passed during script runs to select the instance, browser, and location, enabling a single script to run across different environments.

A single script can be run in different browsers, instances, and locations/regions/OUs without making a change in the code and same can be executed from OTM as well.

Example of how to pass arguments: -env UAT -LOC UTK -browser-type Chrome

What processes are followed to reduce script maintenance and make changes with minimal effort?

Test automation maintenance is inescapable so for improved efficient script maintenance and making changes at a faster pace, function libraries and Page Object Model (POM) are used.

• Function Libraries: Reusable methods for common/utility features (browser launch, login, logout, etc) and Module based/Application specific functionalities (Purchase/Sales Order Create, Approval, Receipt/Invoice creation) are created which are being used in the scripts based on the requirement.

Example: CommonLib, EBSLib, WebLib, P2PLib, O2CLib, FnALib, etc.

• POM: Object repository for Web and Forms elements are maintained here as it reduces duplication and improves maintenance.

Apart from Function Libraries and POM, User.properties and Config.properties file also helps in script maintenance and making changes faster by providing provision to update the User details, credentials, and application URLs.

How is input test data managed?

Currently, Input Test Data for running the scripts is managed through CSV files but our framework, supports databases and Excel files for greater flexibility.

Automation report generation

We have provisions to provide and generate HTML Reports with Test Cases Execution Summary with Pass/Failed status with graphical representation and snapshots of the particular Test Case at Release, instance, region/location/OU, and at an Individual execution level by running Report Generation script.

Storing of the execution reports in the respective folders as per requirement is easy. User needs to change the RunName and ResultsPath parameters in Config.properties file. Also, previous/historical reports of the same script executed can be stored as an archive by updating the ResultOverride as Yes or No in the config file.

With these, more flexibility is given to the User/Business on how they want to store and view the reports.

Conclusion:

Automation testing is the need of the hour, with powerful frameworks, and tools enterprises can solve the challenges of time-consuming testing procedures, system integration failures, outdated test scripts, meet compliance requirements, and more.