Grid-Tools

Why are you still using copies of production databases for testing?!

Posted on 01. Jun, 2010 by Huw Price in Test data

So what’s it all about? As you sit looking at a new set of testing and development requirements, it can be easy to lose track of the basics.

It should be about application usability; improving customer experience and business efficiencies. All simple stuff but an understanding of the role of each business function and a clear grasp of how they interact isn’t always so transparent.

The fog descends…

And so when it comes to testing, it seems the safest option is to use full copies of production data rather than trying to skim or cherry pick data to meet requirements. A copy may be big and slow but it is, at least, complete.

At first, that can appear the safest route when compared to drawing an arbitrary line under what data might be needed (only to find further down the line that the referential integrity has been broken).

But full copies of production data are unwieldy and although selecting subsets of data can be a risk – as tables are tied to each other in increasingly complex ways – it can be done.

There are tools that allow you to view and build on data as the subsets are being designed, that will allow you to drill down through different applications to make extracts, that can shrink and compress data, reorganise tables into different tablespaces as required, to date shift if needs be and so on.

With time set aside for efficient subsetting at the outset of a project, there comes a host of advantages. Speed, efficiency and even the opportunity for different teams to work on different projects using these nimbler subsets rather than full or refreshed copies of production data.

A simpler way to target and enhance application usability. The fog can lift.

Tags: compress database, data subset, data testing, database, database subsetting, production data for testing, subsetting, test and development requirements, test data, Test Data Management, testing