Test Data Strategy Success: Tech Debt & Data Delivery

Delays in testing are often due to testers waiting for data. These data provisioning bottlenecks are generally caused in part by an organisation’s lack of understanding regarding their data and how it flows between their systems. In fact, nearly half of all teams reported that they’re unable to manage the size and complexity of their test data sets [1].

Lacking understanding of complex data is a form of technical debt. Fortunately, there are ways to pay it off, in turn improving the delivery of data to your teams.

This blog sets out how organisations can build a successful test data strategy, including a centralized test data capability. This central test data team can then be used to assess technical debt, start paying it back, and avoid data provisioning delays.

This blog is part 3/4 in our series focused on test data strategy success. Check out the other parts here:

• Test Data Strategy Success: Data Regulation
• Test Data Strategy Success: Technology and Methodology
• Test Data Strategy Success: Tooling to Meet The Strategy

Learn how you can transform the relationship that your teams and frameworks share with data by reading our Test Data-as-a-Service solution brief!

Organisational Tech Debt

When it comes to data, do you know where technical debt exists within your organisation? In software development, technical debt is the implied cost of additional work caused by choosing a quick fix solution now, instead of using a better approach that would take longer but yield better long term results.

Technical debt is often seen in organisations with one or more of the following symptoms:

1. They don’t understand the data they hold in their systems.
2. They have data models that have become out of date.
3. They don’t understand the data flows within their organisation.

There are many reasons why these symptoms might emerge:

1. The dependencies between systems;
2. The rate of change means that you don’t have the time to keep these data models up to date;
3. No gap analysis has ever been carried out – and nor has any attempt to close the gap.

In many ways, test data delays are an example of interest an organisation must pay for their technical debt.

Paying off The Technical Debt

Often, organisations choose to deal with data-related technical debt in order to align with global data regulations. By contrast, organisations that start to pay down their technical debt as soon as possible see an acceleration in their testing effort, including the ability to source test data. But what can you do to help pay back technical debt when it comes to data capabilities at your organisation?

One key way that your organisation can start paying back technical debt is by carrying out data analysis and profiling. At Curiosity, we provide extensive capabilities in both. Once implemented, you can use comparison capabilities and living models to help you stay on top of your understanding of changing systems and data structures.

These techniques, and those discussed in part two of this series, help keep you efficient well into the future. Learn more by watching the “Organisation Tech Debt” episode of Rich Jordan’s Test Data at The Enterprise series:

Who Delivers The Data?

Throughout our test data strategy success blog series, we’ve covered a range of principles and test data management aspects to consider when setting up your test data capabilities. However, we’re yet to ask a key question: Who in your organisation should deliver test data? Should you centralise or federate test data responsibilities?

Assembling a test data team and thus centralising your organisation’s test data capability can save time and avoid dev teams waiting around for data requests to be fulfilled. However, in some cases, you may have a simple requirement for test data. In this case, there’s no better reason for a test team to do it themselves, either by creating or self-serving the data they need.

In other, more complex cases, you are going to need a specialist team to create test data. They will also be needed to engage other support functions in your organisation, for example IT security and data compliance.

A major starting point for understanding who should deliver data in your test data strategy is to understand whether your test teams are testing the system where the data is mastered. Or, do they need to consume data from another system?

As much as test teams want to be self-sufficient, they probably don’t know how to effectively source the data they require and therefore end up becoming reliant on another team to provision the data. A better strategy in that circumstance is to work with a centralized test date team, to ensure that the request and provisioning process is as efficient as it can be.

Benefits of a Centralised Test Data Team

The benefit of a centralised test data team in this scenario is that they are dedicated to fulfilling test data requests. Your dev and test teams will therefore be able to focus on their work instead of waiting for data requests to come in from another team.

There are other benefits to having a centralised capability for test data in your organisation, including the ability to standardize test capabilities and technologies around common data attributes. Review the Data Regulation blog of our test data strategy success series, and think about how a centralised team can help manage PII (Personal Identifiable Information) and SPI (Sensitive Personal Information). Additionally, consider the economies of scale: Does each team need its own data capabilities, or is it more cost and time effective to source that data from a single team?

No matter who manages data at your organisation, it’s important that they are conscious of and facing the questions we’ve discussed in this series of blogs. Additionally, they require the skills necessary to overcome the hurdles that will inevitably come to light when you seek to understand the data in your organisation.

Learn more by watching the “Who Delivers The Data” episode of Test Data at The Enterprise by Rich Jordan:

Successful Test Data Delivery

Working towards reducing technical debt and improving data provisioning at your organisation is key to implementing a successful test data strategy. Consider the questions raised in this blog and the whole blog series so far; being able to address these concerns will help you create an effective test data capability within your organisation.

Here are five key questions that you should be able to answer when it comes to technical debt and data delivery at your organisation:

• Are my teams delayed today because we don’t know how a system is supposed to work – and do we have a plan to address that?
• Do you have a strategy for making sure you aren’t accumulating technical debt going forward?
• Do your teams have simple data requests or are they complex, spanning multiple systems?
• Is your team capable of continually facing into and updating your test data capabilities?
• If sourcing data from external teams, do you have the capability and processes in place? And are they as efficient as they could be?

Knowing the answer to these questions will help you improve your testing and deliver a far more effective test data strategy!

Watch the complete Test Data at The Enterprise series by Rich Jordan to learn how you can introduce six tenants for a better Test Data Strategy at your organisation!

Footnotes:

[1] Sogeti, World Quality Report, 2021-22. Retrieved from: https://www.capgemini.com/insights/research-library/world-quality-report-wqr-2021-22/