Try searching some of the most popular career and job sites for Test Data Governance roles; I did and found just 15, none of which were directly associated with my search criteria. Upon closer inspection, these roles only scratched the surface of what is meant by test data governance. Why? It is because test data governance has been traditionally overlooked due to the assumption that test data will somehow appear in development when needed.

As a developer, our seed data has traditionally come from handcrafted master files, locally created transactions or by executing in a localised environment. As testers, data has often been prepared in spreadsheets or included in test case definitions. However, the emergence of additional tasks such as load and stress testing, security and on-demand automation, these methods have become inadequate; the need for data has grown.

With more and more businesses adopting Agile development practices, Continuous Integration build processes, unit level tests and behaviour-driven development, this need has further increased. Yet, demand has not been met with sufficient support to integrate data provisioning into development. Without this, efficiencies gained through good design and build techniques are negated by delays in confirmation and meeting test requirements.

Traditionally, Database Architects have been expected to understand the data models, supported by engineers that could generate data with often limited scope, leaving the maturing creation of the data to the consumers. Today’s demand on data includes:

·    Volume
·    Continuous Integration
·    Multiple test environments
·    Legacy integration
·    Off-shore
·    Outsourced
·    Silo development efforts
·    Masking
·    Obfuscation
·    Configuration management; versioning and branching

If you are new to data provisioning, hopefully you are beginning to see the growing concerns in this area and how a bottleneck is appearing within modern IT developments.


As an advocate for Agile practices, I have experience of a number of approaches that support these demanding requests for data. The initial secret is to accept that Test Data Provisioning (TDP) must be part of your solution, on par with design, coding, architecture and testing. Creating a scalable TDP team, in proportion to request velocity and environment, begins to address this. However, unlike Scrum or XP methodologies, where the team is responsible for the creation and support of their consumables and their general needs, the role of a Test Data Provisioning team is that of a higher level architect.  TDP teams are expected to understand data definitions, volume, usage and versioning needed to support a successful on-demand practice that can meet these increasing demands.

Personally, I believe that the word ‘governance’ has been misappropriated by senior managers to justify roles, salaries and where budget is being spent. As a Quality Leader, the PMO (Project Management Office) is a natural nemesis – the ‘M’ is a misnomer, ‘A’ for administration would be more apt! The source of this contention is the value to the customer of allocating and tracking work at a high level. So much time and effort is spent on the PMO where leaner, more streamlined processes would obtain the same results. As an Agilest, I believe in ‘individuals and interactions over processes and tools’. However, as the Agile Manifesto points out, there is value in the latter, but I perceive more in the former.

It is time to discover better ways of developing software through empirical practices and innovation. Tools should complement the execution of the process, not vice versa. Do not let the tools take over; use them where value can be found. Test Data Provisioning does not necessarily require a heavy tool. Look at your needs for provisioning data and the make-up of the data to determine which tools are needed and how best to maximise their value.

There is no shortage of tools available; some of the larger vendors offer closely integrated suites of solutions, whereas smaller vendors tend to focus more on tools for specific tasks, such as masking or multiplying for load testing. The best tools offer a modular approach and include features that are important to the production of data that is ‘fit for purpose’. Do not pay for features you do not need but make sure you select a tool that can provide value to your methodology and adapt to the changing nature of modern development environments.

For larger organisations, good test data governance is needed to ensure success. If your developers produce code and the data is subsequently unavailable, the value of testing early and often is lost. Your methods and tools must align with the workflow; this is the governance required to achieve an Agile support infrastructure. However, if governance is not established throughout the development lifecycle, the results will quickly be visible; failure to deliver valuable working software on time, in scope and on budget.

Test Data Provisioning is a new role within the umbrella of Test Data Governance. It encompasses the best parts of database architecture, testing practices, unit testing and security requirements by building the necessary data in short time and placing the system under test in a position to prove the data fit for purpose. Test Data Governance will begin to gain momentum and become recognised as best practice for supplying customers with a highly effective service, regardless of location, functional alignment, security requirements and reporting infrastructure.

With an increasingly widespread acceptance of the Agile principles, the value of a Test Data Governance infrastructure can no longer be ignored.

Ray Scott has over 25 years’ experience in the IT industry, including 15 years as a project development lead. His newest venture is GT Agile, Grid-Tools’ Agile Consultancy Practice.