{{announcement.body}}
{{announcement.title}}

Is Your Test Data Waiting on Your DevOps Team?

DZone 's Guide to

Is Your Test Data Waiting on Your DevOps Team?

Or is your DevOps Team still waiting for the right test data?

· DevOps Zone ·
Free Resource

Is there anything more frustrating than to be stuck waiting? Regardless of what you are waiting for, it’s not a good place to be. According to the 2018-2019 World Quality Report (WQR) published by Capgemini, “…the lack of test environments and data is the number-one challenge in applying testing to Agile development." That means a lot of waiting and a lot of frustration.

Businesses need applications, enhancements, and fixes to be deployed at a velocity never before seen. Once the domain of small, nimble start-ups, even the largest of the large IT shops are getting in on the DevOps act, all for the promise of speed-of-delivery. As more and more organizations implement DevOps and CI/CD processes in order to keep pace with business demands, these issues are becoming more acute.

DevOps is making a difference, but in many cases, it is falling well short of the desired return. While the reasons are many, one common roadblock is the lack of the right test data, in the right place, at the right time. The same WQR notes that 58% of respondents still rely on manually generated test data and 66% said they use spreadsheets to manually generate new test data.

No one should be waiting while test data is manually created; nor should they be waiting on the massive load and reload of entire copies of production database extracts into their integration environment once a year.

TDM Can Remove the Test Data Bottleneck

Waiting for the right test data in the right place at the right time can become a thing of the past. Test Data Management (TDM) technology and tools are not some new, latest-greatest technology here to save the day. These tools have been around for a while, but were largely only accessible by large organizations willing to invest seven-figures for licenses along with similar outlays for multi-year tool implementation projects. These tools added security and control, but all but the savviest of implementors were saddled with the complex and time-consuming problem of loading their lower environments and relying on a central team with unique tool training to pull it off.

There simply can be no tolerance of that for organizations that are invested in DevOps. The good news is that there are now a number of new entrants in the TDM market that rolling out products and features that are specifically geared to DevOps environments.

What sets these tools apart?

1. Small Sets of Data

There is no need to test with the entire production copy, and more importantly, enduring the wait for it to be loaded and scrubbed. The ability to create small test sets, tailored to a specific test case, and load them fast is the starting point.

The ability to grab relationally intact data sets across integrated platforms is a necessity. This should not require additional scripting or other magic to make happen. A DevOps TDM tool will have this capability perfected.

2. Pre-Provisioned Data

To avoid waiting, developers and/or testers must be able to provision the test data as they are building stories and test plans. The data should be available in advance of code being written. The small, focused data sets described above can be stored in a test data repository for use when they are needed.

As long as the test case is still valid, so should the data be valid. Changing the test case should at the very least prompt the user to revisit the test data needed and refresh the data set(s).

3. Naturally Complex Data

Most everyone in the application development community understands that your production data is “the best” test data you can find. What they mean is that test data generators struggle to recreate the naturally recurring complexity that is found in your production data. As such, important edge conditions are missed.

For simple applications, you might be able to get away with using generated data. In complex environments, you need a TDM tool capable of safely leveraging your production data.

4. Safe Data

A copy of your production data may be your best test data. However, not obfuscating that data would be a big mistake, especially if your databases contain PII, PHI and/or PCI. The good news here is any credible TDM tool is going to do some level of obfuscation – even the older tools.

What sets newer tools apart is the ease in which they can consistently mask data across multiple tables and multiple databases. This might not be an issue for unit testing, but it becomes a significant tool requirement in your integration and UAT environments.

5. Self-Served Data

Who makes all this provisioning and protecting of test data happen? In many organizations, there are dedicated teams that run the TDM tools. Smells like a bottleneck waiting to happen, and usually, it is. Because many older tools are very complex, special skills are required, which leads to a specialized team. Even organizations not doing TDM may rely on a dedicated team of test data harvesters to write complex queries using ETL tools and then apply simplistic scripts to provide some minimal level of masking to the sensitive data.

Alternatively, TDM tools made for DevOps feature intuitive, easy-to-use interfaces that allow developers and testers to create their own small, safe copies of test data from production sources. The best tools require minimal training to get your resources up and running.

It’s Time Your Test Data Was Waiting for You!

Don’t let the lack of readily available, naturally complex, and safe test data derail your DevOps investment. Do your research. Find tools that can be integrated into your process. Not sure you know how to sell the concept within your organization? Take a look at this article which lays out the creation of a TDM business case.

Topics:
devops ,devops testing ,test data management ,devops tooling ,quality assurance and testing ,devops quality assurance ,devops qa testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}