It is often observed that our customers struggle with testing automation. This blog article was created to exploring some testing options and hopefully help to guide customers to create and automate their test plans. 

Testing a CPQ application

It’s very important that an Oracle CPQ Cloud Application be thoroughly tested to evaluate and improve quality of custom modules and/or functions. But manual testing takes too long and opens a chance for errors. Therefore, it’s always better to automate as much as possible. It’s recommended that the QA team focus on creating automated test plans and analyze the recordings of automated tests. This could take a lot of effort, but it is an absolute must to prove custom code works. You need to prove that your customization works! To accomplish that goal the following suggestions are offered.

Select testing tool

There is a large assortment of automated tools and ultimately, it’s the customer criteria to select a testing tool that fits their organization. But for those that would like some guidance, Oracle CPQ Cloud customers typically have selected in the past Selenium and were happy with it.

Automated Functional Tests

Once the testing tool is selected and procured, Automated Functional Tests should be created from use cases and/or requirements. Every possible choice in the configurator or commerce actions, should be included in the test suite. Negative testing, using invalid data or undesired user behaviors, should be used to check for unexpected system errors.

It’s highly recommended that code with integration calls be tested with and without the integration system. An easy way to conduct this type of testing would be with mock calls, which is a technique used where the original integration call is replaced with another object (perhaps an util function call) created temporarily to simulate the behavior of the external system call. The advantage of using mock testing for integration calls is to remove the potential latency of the external system calls.

Automated System Tests

Now that it can be proven through functional tests that the custom functions and modules work as expected, it’s time to disable the mock calls and replace with actual integration calls. Again, all choices in the configurator and commerce actions, should be tested once again with the actual integration calls being used. Negative testing should also be leveraged to ensure coverage.

Automated Regression Tests

When functional and system tests are completed and the coverage percentage is high, Automated Regression Tests should be executed in UAT. It is also highly recommended that the entire test suite be executed in UAT after each patch or version update.

CPQ Testing Bottom Line

• Test every time new code is deployed or changes happen on environments
• Never test in production. If a problem is discovered in production, test in UAT.
• Tests should have a report to “prove changes in code and configuration did not break the application.”
• Automate as much as possible and measure all the time.
• Leverage mock testing for integrations.

  I often observe that our customers struggle with testing automation. This blog article was created to help by exploring some testing options.

Conclusion

It’s very important that an Oracle CPQ Cloud Application be thoroughly tested to evaluate and improve quality of custom modules. This will ensure that code perform as desired and also that it does not increase latency. There are a number of test suites (functional, System, Regression, etc.) that need to be created and executed on a regular basis and it’s not manageable to execute these test suites manually, therefore automated testing is preferred.