Rich Jordan, Enterprise Solutions Architect from Curiosity Software introduces six tenets for a better Test Data Strategy. A POV on overcoming the much-cited industry analysis of Test Data being as one of the biggest blockers to fast and effective testing within organisations today.
So, delve into the six key ideas you should really be able to put answer to as part of your Test Data Strategy to ensure that data isn't a blocker to your testing efforts:
Data Regulation: what regulations do your organisations near to adhere to, but more broadly, what are those regulations underpinned by in terms of policies and standards in your organisation; and how do they affect the way that you handle data and the way that you would design your IT systems.
Architecture and Technology: organisations will have a spectrum of technologies, both old and new. How do these technologies and the way they integrate create challenges in the way that you test and the way that you get your data into your systems to allow you to test.
Delivery Methodologies and Test Approach: with many organisations working in an agile methodology of some capacity of say, two week sprints, an effective Test Data Strategy also needs to be agile to be able to deliver to those same timelines.
Organisational Debt: many organisations will struggle to maintain a good or up-to-date understanding of the data within their systems or how the data flows between their systems, especially in organisations that have legacy platforms or many systems that are highly coupled.
Who Delivers the Data: many delays in testing are down to testers waiting for data to be delivered to them.
Tooling to Meet the Strategy: too many organisations rely on rudimental tools and techniques to create test data.
At Curiosity Software, we've compiled individuals and technologies helping many organisations overcome these types of challenges over the past few years. In the next video, the first of an initial six, we'll cover the topic of Data Regulation.
What regulations does your organisation need to adhere to, but more broadly, what are those regulations underpinned by in terms of policies and standards in your organisation?
Speaking with industry insight, Rich Jordan, Enterprise Solutions Architect from Curiosity Software, considers there’s a need to identify and categorise data in two specific ways: at an IT System level, but also an organisational level, ie, data flows and data models.
In effect, GDPR regulation needn’t limit your test data capability, and not all live data should be considered as personal identifiable information (PII), sensitive personal information (SPI), or commercially sensitive information. If you're actually complementing these regulations by fully understanding how your organisation deals with sensitive data you can deliver a far better and effective test data strategy and accelerate your testing journey.
Architecture & Technology
Organisations will have a spectrum of technologies, both old and new.
Rich Jordan, considers the typical question of how to best extract and inject data into these technologies.
Taking the architectural principle of Loose Coupling could this help managing integrated systems, ie, going from Mainframe to SQL, then to NoSQL databases, or be a useful principle for such an event streaming architecture like Kafka or a Microservices architecture?
Ultimately, do you know what are your organisation’s core technologies which hold data and how they relate to any architectural principles already implemented?
The benefit is that you’ll be concentrating test effort and minimising the volume of test Data needed.
Delivery Methodology & Test Approach
With many organisations working in an agile methodology of some capacity, ie, two-week sprints, an effective Test Data Strategy also needs to be agile in delivering to those same timelines.
Rich Jordan, highlights the importance of challenging your test team’s scope and also ensuring communication between the test team and those responsible for provisioning test data is sufficient.
Usually, data can be shored up by having a good understanding of the system under test. A final thought for consideration is can you identify the delivery methodology your test teams are currently using and to what extent your Test Data Strategy aligns to it?
Organisational Tech Debt
Many organisations will struggle to maintain a good or up-to-date understanding of the data within their systems, or how the data flows between their systems.
Rich Jordan, suggests this level of organisational tech debt can be paid-down, leading to a better understanding of the changing systems and its data structures.
It’s typically seen in organisations with legacy platforms or where many systems that are highly coupled.
So beyond the regulatory ask, your organisation will need to do data analysis and profiling to accelerate the journey for paying-back organisational tech debt, but do you know where this technical debt exists in your organisation?
Who Delivers The Data
Many delays in testing are down to testers waiting for data to be delivered to them.
Rich Jordan, suggests that assembling a test data team and thus centralising your organisation’s test data capability will gain you time and avoid dev teams waiting around for data requests to be fulfilled.
Beyond this time saving benefit, a centralised test data capability helps to standardise around common attributes, like getting PII anonymised.
The ultimate ask though falls on economies of scale, ie, does each team need its own data capability or is it better on time and cost to source that data from a single dedicated team?
Tooling to Meet The Strategy
Too many organisations rely on rudimental tools and techniques to create test data.
Rich Jordan, proposes that tooling alone isn’t enough, and that a good Test Data Strategy also addresses the range of capabilities and complexity of expertise the tooling adds to an organisation.
At entry level, do you understand where PII exists (profiling), where technical debt is in the system (comparison), and which data needs anonymising (masking)?
More fully, what’s the size and shape of your data (synthetic data gen), the pace and efficiency (subsetting to shrink data volumes) of usage?
Or for an ephemeral environment strategy around DevOps (virtualisation) how do these all inform strategic decisions about tooling?
Ask yourself, do you have the requisite tooling that helps you understand and resolve the problems you are facing when it comes to test data?