Regression testing and automated testing are incredibly advantageous for your HCM operations. Before you begin, it’s important to understand what regression testing is and how you can automate it to save time, money, and unnecessary headaches for your business. Below, we’ll answer some of the common questions regarding regression testing.

What is Regression Testing?

Regression testing is a philosophy and process in which customers manually perform “tests” to the Oracle application after updates.

How do I prepare for regression testing?

Historically, testing best practices included a process for customers in implementation. The  customer would perform systematic testing on the Oracle application in each and every phase of the project such as UAT (User Acceptance Testing) or SIT (System Integration Testing). That would become a model for the customers’ standard testing “use cases” when a new update was applied to the application.

However, regression testing needs have evolved.

Follow This Regression Testing Process 

First, ask yourself, “What are the critical processes that we have to have for our organization to function? “

Consider the following for payroll, benefits, hiring, and standard flows:

• Worker flows
• Interfaces
• Reporting
• Extracts

It’s important to run payroll in staging to test prior to update, test at roll back, and re-test after update.

Many customers have a repository of manual testing scenarios that they call regression scripts or testing scripts. You can create your own repository of tests and add them to them as you implement new parts of the application or as your footprint grows and changes.

What is the Blueprint for Regression Testing Oracle Quarterly Updates?

In terms of regression testing your Oracle quarterly updates, Oracle partner, Opkey, has developed the following blueprint:

The Blueprint: CARD

C – Know your ideal test Coverage

A – Assess risk with every change

R – Regression

D – Documentation

C – Know Your Ideal Test COVERAGE

Some questions to ask at the beginning of regression testing:

• What are my most used Business Processes and the variations of it?

• What is a realistic dataset based on my production data and user tx?

• From a non-functional perspective, what is important? Security? Regulatory requirements?

• What are most important integrations?

• What are my standard and custom reports that need to be tested?

Once you’ve answered these questions, then you’ll follow these steps:

1. Create a test plan based on coverage analysis.
2. Assess your testing bandwidth and train people in advance.
3. Prioritize and re-prioritize.

A – ASSESS Risk with Each Change

Consider these questions regarding risk:

• What are the changes coming in the next release (Advisories and release notes)?

• What are my objects at risk and transactions at risk?

• What is the possible impact to my security roles and privileges and integrations?

• What is the impact on GEOS?

• What is the impact due to new features being enabled?

Next, you’ll follow these steps based on those assessed risks:

1. Identify tests that will cover the risk.
2. Check to see if tests need updates based on changes in workflow.
3. Segregate your test suite based on risk.
4. Prepare integration testing environment based on risks (APIs).

R – Run Your REGRESSION Tests

At this point, no questions are needed. It’s time to act. Follow these steps:

1. Run sanity test on Day 1. Ensure the system is testable with no more than 50 tests.
2. Prep test data.
3. Execute tests based on risk profiles.
4. Run the full regression suite if time permits.
5. Follow daily defect triaging with data issues vs. Oracle issues.

D – Review and DOCUMENT for the Future

• What kind of Test Documents do we need as a last mile quality gate?

• Do we need some audit specific documentation (Validation for GXP)?

• Is my test coverage covering all risks appropriately?

• What went right for us and what can we improve?

Then take these steps to position success for the future:

1. Prepare different reports for different stakeholders.
2. Update test case documents based on what you’ve learned.
3. Update test data sets based on what you’ve learned.
4. Share your findings company wide.

Here’s a look at best practices for testing quarterly updates:

To learn more about Opkey’s methods consider watching the following video from Quest’s Cloud Week: The Essential Blueprint for Regression Testing Your Oracle Cloud Quarterly Updates.

Am I ready for Automated Testing?

Before you consider automating your manual testing, ensure that you have a very detailed and standard process on manual testing. Do you have key teams and groups in place to execute a successful regression test across all groups in your organization. Make sure you have the following areas covered:

• Planning
• Execution
• Regression
• Defect Management
• Report Outcome & Success of Testing Pass/Fail
• Responsible Party for Re-Testing, SR Management & Resolution
• Responsible Party for Downloading “What’s New” Documentation & Identifying Impact

What is Automated Testing?

Test automation is the practice of running tests automatically, managing test data, and utilizing results to improve software quality.

Why should I use Automated Testing?

Here are 3 reasons automated testing makes sense for your business:

1. Reproduceable Results — Testing is performed the same way each time. It’s complete, meaning no scripts or steps are skipped, and there is no human error.
2. Scalable & Comprehensive — You can test everything, easily adding scenarios through repetitive sections and a data repository. It allows for executing negative tests, which test for error conditions. You can also sequence consecutive tests, schedule execution, and receive thorough, detailed documentation with screen shots and date/time stamps. You can use it to document configuration and processes.
3. Less Expensive than Manual Testing — Greater testing efficiency leads to increased cost savings and more testing. The automation is less time consuming for your business. It frees up internal resources and schedules execution of tests. You’ll receive a detailed documentation output. Plus, the fixed price model means predictable costs for your business.

Typical testing scenarios include:

• Cloud SaaS: Monthly/quarterly updates
• JD Edwards: ESUs and code current events
• Projects: Test cycles (CRP, IST, UAT, etc.)

What is Test Automation Buildout?

For Test Automation Buildout, test scripts with all steps within software are set up.

The scenarios are represented by sets of data in a data repository. Test consolidation takes multiple test scenarios and combines them into a single test which repeats for each scenario. Separate tests which require sequential execution are combined and subsequent test steps use the data created in prior test steps.

Below is an image of the test automation buildout performed by an Oracle partner, Argano:

When automated testing occurs, your test script and data repository (think of it like a spreadsheet built into the tool) execute and output to either Xcel, Word, or Adobe PDF. The output will look something like this:

To learn more about Argano’s test automation buildout you may consider watching the BLUEPRINT 4D session: 3 Reasons Automated Testing Makes Sense for Your Business.

Key Takeaways

In conclusion, regression testing can be overwhelming. To ease stress and the pull on business resources, you can automate regression testing.  For more information on automated regression testing and applying updates in Cloud HCM, consider watching the BLUEPRINT 4D presentation: Recommended practices for applying updates and taking regular maintenance in Oracle Cloud HCM.

For more on Oracle Cloud HCM, check out Quest’s Content Library.

To connect with other Cloud HCM users, you may considering joining Quest’s Cloud HCM Community.