Jo  Wright
15 Jul

Why data testing is a Boardroom issue. But all too often is not

15 July 2011 by Jo Wright

So once your products are all they should be, what then? The clue is in the paragraph above, i.e. 'customers expect'. And boy, don't they, and if companies lose sight of the need to match good products with even better customer service, they'll be undone.

And what can possibly help organisations manage the countervailing pull of product, service and innovation? It's data. Lots of lovely data and the systems they feed. Business systems that oversee sales processes, monitor peaks and troughs, hunt for evidence of trends and manage customer contact strategies that enhance rather than destroy customer relations.

Not hacking customers off is a 21st century requirement, something that United Airlines will be sensitive to after a disastrous day last month. I can't pretend to know what lay behind the computer system shut down but developers and testers acknowledge that although it takes a huge effort to manually create data to test new functionality, that effort does not result in data that tests all scenarios.

The business case for synthetic data is now clear as it is the only way to create data with a rich enough spread to go beyond examining how data performs in existing systems and scrutinizes how functionality will hold up in the parameters of new.

So, with business systems at the very heart of how companies function and indispensable when determining strategies to maintain growth, why isn't data testing and development a front-of-mind, non-negotiable, number-one priority?

My view is that even today in the boardroom, the big cheeses don't get it. Not enough CEOs were CTOs.

Too many 'C' level honchos are happy to sketch out what they want to see grafted onto a business but too few appreciate the time it should take to develop systems. With the 'it should have been done yesterday' pressures of today's business environment, time is money but get the planning stage wrong and the costs are almost incalculable.

Few would trust a carpenter to start building a cabinet without plans, and thorough plans at that, so why do businesses tolerate minimal resources for testing?

Soon enough, the use of synthetic data and comprehensive test data management strategies will be the norm. And as an ordinary consumer, it can't come soon enough.


1 comment(s) for “Why data testing is a Boardroom issue. But all too often is not”

  1. Gravatar of Steve Littlejohn
    Steve Littlejohn Says:
    I agree with you Jo to a certain extent. The trouble with many older companies is the organic growth of the systems before legislation was brought in such as the Data Protection Act. Data back in those days could be used with impunity and a copy of production data was either relatively easy or a difficult chore as data tools were expensive and few and far between. As least then there were normally restrictions about who could see or use the data in the environments although obfuscation was never used. The data grew over the years however, as testing was always done that way, the data was either recopied or had to rely on occasional refreshes to keep it valid. Mind you I should point out that a refresh was normally just to add new Production data rather than clear it down completely. Due to this the preception that data is a problem is hidden from the 'C' levels, its been running smoothly for years, there's a bit of grumbling but that's standard for a bunch of techies - right?!

    These days with so many data losses companies are becoming more aware that the data is an issue. They might start with addressing their security and data quality in Production but for testers hopefully it is only a matter or time before they realise what testers are using to test. The data could be in any state but it is for the most part still Production data - and could still be a cause of embarrassment if it escapes the test environment.

    In my many years experience of investigating and improving companies' use of data I have rarely found a company that can easily supply obfuscated, integrated (across the data landscape)sets of data for test environments that fully meets the tester's requirements. There are a lot of perceptions out there - its production data so it provides 100 percent test coverage, its safe to use production data copies for testing mailing systems, its a test environment so it doesn't matter who sees the data, users always need to see production data or they can't understand it and so it goes on - but these are excuses to avoid solving the data problems.

    It is a boardroom issue in that the 'C' levels need to understand that they have serious issues at the "coal face" from which their systems are mined. It is the CTO that has to make them understand that data protection breaches are probably happening every day without recognition within their test environments. Production systems tend to be ring-fenced and secure but their test environments are being exported, with their copied Production data, to various parts of the world as part of outsourcing deals. Once this is realised and addressed the testers for once might actually be able to get the right tools to obtain or create the right data at the right time. Perhaps its also time for testers to rise up and point out the dangers of the data in the test environments!

Leave comment: