Lire cet article en Français 
Automating Testing for Data Analytics
in the Retail Industry
Run Your Business with Trusted Data Analytics in the Retail Industry
Most companies have sales reports and analytics that are business critical. Everyone, from front-line staff to the C-suite uses them to make important decisions. This puts tremendous pressure on those responsible for developing and managing these reports to make sure they house trusted, accurate insights. Fortunately, automating a testing process around the most critical elements of sales reporting is possible—and developers can be alerted to errors, so that they can be investigated and addressed before bad decisions are made.
Below are some common issues that occur with sales reporting and data analytics in the retail industry, and how these can be addressed at scale with automated testing.
Check for the Latest Orders & Shipments
It is hard to use sales analytics to make good business decisions without the latest data! This is especially true if your reports are updated daily—or even more frequently. Setting up tests to automatically check for the presence of the latest data is a breeze with Wiiisdom.
In the example below, we have selected a column “ORDER_DATE” in a sales table in our dataset, and set up a simple test to be sure that the most recent (maximum) date in the column was what we expected it to be. The best part—this test can be set up using a static or dynamic date. In the case of a dynamic date, a simple check could be performed to be sure today’s date was always present in your dataset.
TIP: make sure you set up this test to run after your database tables have been refreshed, and when the data is expected to be available in the dataset.
Example of setting up a test to check for the presence of the latest data.
Detect Any Unexpected Customers, Items & Product Categories
Sometimes new values can unexpectedly enter a sales report, wreak havoc for users and lead to a lot of questions for the report developer! You can make these unexpected questions a thing of the past by setting up automated testing on the values in the most critical columns in your report. In a sales report, these could take the form of:
- Unexpected customers.
- Unknown items.
- New products that haven’t yet been assigned to a product category in your product taxonomy.
In the example below, we’ve set up a test to check to be sure that we don’t have any values in the SUB_CATEGORY column of our products table that are unexpected. These could result in sales dollars appearing in our reports that are not associated with the expected product sub-categories that a user would expect to see.
Example of testing for unexpected values in a specific column.
A test could also be set up to check for the values, and only the values, that would be expected in a given column. If you have lists of customers or product taxonomy tables with SKU/item numbers, product categories, etc., you could simply upload these and perform continual checks to be sure no values outside those in the list are present in a selected column.
Identify Business Rule Violations
Sales reporting and analytics will often contain common measures such as:
- Orders.
- Shipments.
- Margins.
- Lead Times.
- Discounts.
Automated testing can be established to confirm that business rules pertaining to these measures have not been violated. As an example, an organization may have a business rule that a discount level may not exceed a given threshold. If it does, either a business rule was violated or there is an issue related to data integrity. In either case, the report owner will likely want to know immediately if this occurs.
This can be accomplished by setting up a test such as the one below, that is checking to be sure the maximum discount appearing in a DISCOUNT column does not exceed the maximum percentage allowed by the company. A similar test could be set up to perform checks for other critical business or data rule violations around other key measures in your sales report.
Testing to ensure business rules haven’t been violated on a specific column.
Test for Proper Security Group Assignments
Self-service sales reporting is sometimes set up with row-level security (RLS) in place. When user-defined, this allows reports to display limited information based upon whomever is using the report. For example, a store manager may only have access to data concerning his own store, while the regional manager has access to data concerning his sector, crossing several sales outlets.
Wiiisdom allows you to test to be sure the right data is appearing to the right users. As an example, Wiiisdom for Power BI has a feature that can be enabled (shown below) in the opening step of a testing pipeline to run the testing pipeline as a given user based upon their security group assignment.
In other words – you can test to be sure that John’s sales data does not appear to Jane, and vice versa!
Option to run a testing pipeline as a given user in Wiiisdom for Power BI.
Schedule Tests & Alerts to Run Continuously
Setup tests to run at the time of day that makes the most sense. If your datasets are refreshed at 6AM daily, then perhaps schedule these tests to run at 6:15AM daily. Imagine the power of being alerted to issues before you get to the office and being able to address them prior to your users discovering them.
Schedule pipeline execution feature.
Email alert setup.
Mitigate Risks from Changes to Your Sales Data Source
If you find yourself changing the data source that your sales reporting and analytics use, you will want to test to be sure there are not any expected visual changes to your report. Your orders and sales data may have moved from one database to another, or the retail point of sales data you use in your reports started coming from a different place.
Fortunately, Wiiisdom allows you to take a snapshot of all your reports before data source changes takes place, and then another snapshot after. You can then see:
- Which reports experienced a change.
- What the changes were (highlighted in red as shown in the example below).
This can also be useful when managing through migrations or upgrades to the servers hosting your data. Think of these as instant quality checks and risk mitigation from unexpected changes!
Example of a regression test on a report before and after a data source change.
Guarantee Reliable Sales Reporting and Analytics From the Get-Go
Sales reports and data analytics are vital for decision-making in many retail companies. The responsibility to ensure their accuracy is immense. Thankfully, automated testing can alleviate this pressure by identifying and alerting developers to errors in critical elements of sales reporting. This allows for timely rectification, ensuring the reliability of decision-making.
