Saturday, August 30, 2008
Should I.T. shops test with production data
On this day, 11 years ago, Aug. 30, 1997, I drove west to a “new life” in Minneapolis for six years, after a corporate transfer. It was a happy time, and I even took the indulgence to buy a dressy blazer off the turnpike in Fort Wayne, Indiana.
I think now how much information technology has changed since my “good old days”. In fact, I can walk the clock back further, to September 1, 1987 (a Tuesday that year I think) in Dallas, when I was working for Chilton (now Experian via TRW) and when we ran a full month of parallels of old (assembler) and new (COBOL and Datacomm-DB) daily billing systems, printed all the reports, and put them on a work room. We checked every one and kept them, in print. Then, years later, I’d keep lots of production parallels and listings (and File-AID file-file compares) in binders in my cubicle as “proof” of my own testing of elevations.
Although I haven’t worked in this field officially since Dec. 31, 2001, I can well imagine that work habits have to be much different now, because of the corporate risks of consumer data loss. When I was working, that issue had (even by Y2K, when we ran and saved beaucoup detailed production listings, but eventually shipped them to an iron mountain) not yet received significant media attention.
Now, it seems like it would be risky to depend on production data for QA tests, or at least to let programmers work with it. Whole new testbed layers would have to be built, to scrub production data and make it fictitious, but still represent all the test paths and conditions. Whole teams would be needed for this. Major financial institutions owe the public nothing less than the effort to build these teams. And, by the way, they might create some good old-fashioned IT jobs (in QA) along the way. Who knows, maybe there’s an IT resurrection for me yet.
Oh, yes, I remember a joke from the 1987 parallel. "If it works, it's production. If it doesn't, it's a test." No more.