Enterprise Application Testing: 4 Phases to Expect for Easier Planning

By ArMand Nelson, Director of Strategy

While retailers’ shift to digital technologies and automation isn’t new, the COVID-19 pandemic certainly accelerated it. Brands now rely more heavily on online sales and delivering an easy ecommerce experience is a clear competitive advantage.

This huge undertaking of new technologies, integrations and capabilities requires careful planning and, just as importantly, testing.

Testing enterprise retail applications sounds like a straightforward task, but sometimes retailers misjudge the number of phases and time it takes to thoroughly test new technology.

Let’s take a look at the four main testing phases to help you better prepare and plan for the digital transformation.

The Phases of Retail Application Testing
For most enterprise technology projects; retailers chose a system integrator (SI) to lead the project. The SI should have experience implementing, integrating, testing and supporting the retailer’s selected technology, such as Oracle Retail or NetSuite.

Testing begins after the SI configures the application to meet your business needs. These are the typical testing phases in an enterprise retail technology project:

• Functional (or unit) testing
• Integration testing
• End system testing
• User acceptance testing

Functional (or unit) testing phase
Functional testing “proves” whether or not the configurations can work with your business processes. Sometimes there are surprises or issues that show up during this important testing phase.

If the functional testing reveals problems with the configurations, then you will have to decide whether to change your processes to match how the application operates or invest in modifications.

A modification can be anything from changing an application process to adding a data field within a screen. Modifications may be necessary in certain situations, but they do carry an added cost because you take on the risk of these mods not aligning with future upgrades.

Once you are confident the configurations and mods are working the way you them to, the application is considered “built.”

Integration testing phase
The integration phase tests whether the retail application can correctly “talk” with other systems, such as ecommerce, POS or merchandising.

You and your SI will test whether data flows correctly from one system through another based on how it was designed. You’ll make sure the data is showing up as expected and that reports match up with business needs.

End system testing phase
Now it’s time for the end-to-end system test. From the start of a task to its completion, does the application work the way you expect? Did the data feed into the correct business applications?

Take a look at your most essential processes, like item creation, creating PO’s, receiving, POS, etc. and see how the data flows across all your applications. For example, when the application knows there are goods in the warehouse, it should update merchandising on hand and the commerce site.

User acceptance testing phase
Now that the end-to-end testing looks good, you can move on to user acceptance testing (UAT). This is your last check before the project goes live.

Expect the SI to be a close partner from the functional to end-system testing phases. While they can provide guidance with UAT, this testing phase will be owned by your organization.

Although some employees will be involved in testing from the beginning, the UAT phase is when more employees are brought in to test how their tasks are completed in the new application. Typically, these are functional people or core leads (make sure they are thoroughly trained so they can jump right in!).

These employees will test and confirm that the granular details of the new system or application are correct: Are the menu options where they should be? Are roles and permissions accurate?

Rarely does any testing phase go 100 percent perfectly, so be prepared for adjustments and re-testing. It is not uncommon to have retest each testing phase 2-3 times.

Retesting during a Version Upgrade
Retailers with on-premise applications can typically choose when to upgrade. But if you have a cloud-based application, the decision is probably out of your hands. Vendors may upgrade their technology occasionally or, ideally, have a predictable schedule of enhancements.

Whether you have on-prem or cloud, testing should be done each time there’s an upgrade – whether it’s a new system or an application update. Don’t forget to test your modifications too, in case they need to be redone after the upgrade.

Cloud-based providers will have a test environment where you can ensure your configurations and mods work correctly. Perhaps their enhancements will make your mods obsolete, so you can move closer to base! On-premise upgrades also require testing, so ensure your on-prem test environment looks like the project before you begin the upgrade and testing.

Once you’ve identified what has changed with the upgrade, start your testing from the beginning: the functional, integration, end-to-end and UAT test phases.

Keep in mind that if you get too far behind on upgrades, the version differences will be so large that the project will turn into an implementation rather than an update.

Testing with your System Integrator
There is a lot to test with a new application, yet you won’t be able to test every possible situation. Work with your SI to identify high, medium, and low testing priorities before launch. Your SI should be able to lay out the benefits and pitfalls of any testing plan and be realistic with you about expectations.