…optimise your IT investments Successful approaches for Test Data Management Philip Howard Research Director – Bloor Research

…optimise your IT investments

Successful approaches for Test Data Management

Philip HowardResearch Director – Bloor Research

telling the Information Management storyConfidential © Bloor Research 2009 telling the right storyConfidential © Bloor Research 2012

Agenda

What is test data management?

What would you like from test data?

The options for creating test data

Important considerations


What is TDM?

“The provisioning of the hayloft” by Herman Johannes van der Weele


What is TDM for?


What’s it all about?

Poor quality software costs

The earlier you find errors the less it costs to fix them

Thus you should test early and often

But: that requires that suitable data is available as often as you want to test


What do you want from test data?

Data when you need it (supporting agile development)

No contention for resources

Test data that is representative of the real data

Test data that preserves the relationships that exist in the real data

Where appropriate, the ability to secure sensitive information

Minimal administrative requirement

Support for different sizes of dataset


What is it you want 1?



“Bone of contention” by Nick Hunter





Conceptual view of a business entity








Creating test data

1. Manual cloning or copying

2. Database subsetting

3. Synthetic generation


Manual approaches

Require significant administrative effort

Require significant understanding of data structure and prone to error

Administration effort directly proportional to agility of testing environment

Tends to mean either:Multiple copies of data for each development/testing team

Which is expensive

Contention between teams for resources

Difficult to ensure that data is representative, that relationships are maintained and that data is secure


Database sub-setting

Requires minimal administrative effort once set up

Understanding of data structures is automated

Reduces time to create test cases

Shrinks footprint for non-production environments

Can have different sized datasets for, say, unit vs integration testing

Tools available/built-in to ensure that data is representative, that relationships are maintained (ensuring referential integrity) and that data is secure


Synthetic data generation

Requires full understanding of data structures

Apart from that, zero impact on production environment

Can re-generate data on demand

Data automatically secure

More complex in terms of understanding, compared to sub-setting, but required in some environments


Important consideration: understanding the data


Important consideration: refreshing the data


Important consideration: data masking


Masking requirements


Conclusion

Manual methods of generating test data take too long, are too expensive, can’t ensure proper coverage, are inefficient for data masking and are not suited to agile environments

Test data needs to be representative, it needs to cover relevant cases, it needs to be quick and easy to refresh the data and you need sophisticated data masking capabilities


Documents

…optimise your IT investments Successful approaches for Test Data Management Philip Howard Research Director – Bloor Research