Your customer data stays on the live system

The problem

Developers need realistic data to test with. Made-up data is too tidy. Real data has missing fields, ten-year-old records in formats nobody uses any more, customers with forty addresses, orders that were half cancelled and half refunded. Things that work perfectly with test data fall over the first time they meet the real thing.

So the practical answer, on a lot of projects, is a copy of the live database. On a laptop. On a test server. On the laptop of the contractor who left last year. Nobody is quite sure how many copies there are or who has them, and it only becomes a question when a breach story is in the news or a customer asks what you do with their data.

What we do

Anonymised test data

We work from a slimmed-down, anonymised copy of the live database. A script takes a backup, replaces anything personal (names, emails, addresses, anything that identifies a real person) with fake equivalents, and cuts it down to a manageable size.

The personal details are gone, but the shape of the data is untouched. The missing fields, the old records, the awkward order histories, the sheer volume: all still there. So testing catches the problems that only show up with real data, and no actual customer information leaves the live system. A developer's laptop, the staging server, a test run in the cloud: none of them hold anything that would matter if it were lost.

There's a useful side effect. Producing the anonymised copy means restoring a backup, so the backups are being restored and used all the time. If one stops working, we find out on a Tuesday afternoon, not during an emergency.

What it means for you

Testing is realistic, so fewer problems reach customers. You can answer "where is our customer data?" with a short list rather than a shrug. And the backups are proven to work, continuously, as a by-product of ordinary development.