Adopting the Right Test Data Management Strategy

Challenges related to test data are vast and varied, and increasingly I am encountering the need to have a solution where test cases can pick automatically test data. This is one key aspect of test data management (TDM) solutions. Tools like Smartbear and Tricentis are already doing this to some extent.

The problem we are trying to solve is different. Having data for the test cases comes when you have data in your test environments, and that is what we are precisely focusing on. This is what a TDM strategy should typically address.

In bimodal IT, where digital technologies are the prime focus of front-end applications and legacy systems are still in use, the challenge of providing the right data to test teams has never been so complex.

What is the right test data strategy, and what should we focus on?

We meet multiple customers and respond to a plethora of proposals, and trust me, the test data problem statement cannot be boxed. Test data issues are unique to customers and we cannot have a one-size-fits-all solution. Some of the myths we encounter and wish lists of customers and so-called TDM evangelists are:

• Create 100% of test data and eliminate dependency on production.
• Source 100% of test data from production and eliminate the need to create test data.
• Create a smart data bot that will fetch data based on your test scenarios.

All the above points are good to have and are extremely idealistic. But are these realistic solutions? Are they implementable? The answers to these questions depend on the situation. Your solution and the strategy for test data management is directly a function of your test data needs, technology platform, and “type” of testing you are doing.

For example, if we are testing an e-commerce site where the bulk of the testing is placing orders using the e-commerce platform, you can create the bulk of the test data using an automated solution.

But what about a data warehouse application where terabytes of data are required in hundreds of tables so that the testing team can do data validation? In such cases, there is a little scope of manufacturing data, and hence the source of data must be from production.

Similarly, when your system under test is a legacy application, any kind of packaged application, or a cloud-based application, to think we can manufacture 100% of data is wishful thinking.

Data manufacturing tools, whatever they might claim, have huge limitations. As far as performance testing is concerned, where we are not concerned with data lineage, these tools are useful. However, if the intent is to do business operations testing, it is not advisable to generate the majority of your data artificially. The best and the correct source of data is always from production, or a production-like system, where data is created through the natural business process.

A combination of production plus data generated through automation tools is always the best option.

The table below gives some of the tool options we have.

How can you choose the right tool?

Tool vendors promise the moon, but end users should clearly understand their own requirements, do their due diligence through experts, and then decide on a tool. It is akin to ordering something in a restaurant; if we don’t know how hungry we are and what we want to eat, we end up ordering something that will go waste.

Also, it is very important that customers have a strategic view of the tool needs. Large enterprises have a myriad of applications running on different technology stacks. Looking at TDM needs in silos will lead to piecemeal initiatives resulting in false starts, missed opportunities, and sluggish performance. Below are some of the key features that customers should consider when evaluating a tool:

• Connectivity to a variety different data sources (RDBMS, flat files, mainframes, packaged applications, etc.).
• The ability to mask sensitive information based on country-specific rules (i.e.HIPA, APRA, GDPR).
• The intelligent discovery of data.
• Data profiling.
• The ability to maintain data relationships across tables.
• Self-serviceportal.
• Test data refresh capability.
• Data sanitization.

The TDM technology space is moving fast. Customers have realized TDM is no longer a luxury, but an imperative.