Data Processing Quality Assurance

A data processing system cleanses and transforms point-of-sale data gathered daily from hundreds of retail stores. The data processing system is being replaced by newer, more robust technology so that the point-of-sale data can be gathered more reliably from more stores and delivered to more destinations.

A quality assurance team has been charged with testing whether the output of the new system matches the output of old system. Any discrepancies must be fixed, or in cases where the new technology has improved the data quality, the differences must be documented and explained to the end-users of the data. The processing systems generate over 200MB of information (30,000 records on average) at each of five stages of processing. The QA team has no automated means of comparing the data output of each stage. Each test run takes two weeks, and as a result, the system release date is slipping.

I was hired to help the QA team automate the analysis of the data output.

• Built a series of queries, macros, and reports that compared the massive output of the two systems
• Developed a tagging system whereby errors in the earlier stages could be flagged and tracked through the later stages
• Aggregated test results from each stage into QA reports so the team could track the testing process
• Developed methods to export the results of each test run so progress could be measured between the testing runs
• Contributed to the QA effort by identifying bugs
• Documented the known differences in the output and explained the differences to the end-users of the data

We reduced the time spent analyzing data from two weeks to one day. Each test run of the system went progressively quicker as the known discrepancies were factored out of future tests, reducing the workload on the team. The reduction in time put the project back on track and they were able to release the system on schedule.

During my development days, I was always a stickler for developing quality code. I felt embarrassed when a tester (or worse - an end-user) found a bug in my programs. This project taught me to celebrate when QA finds a bug, since every bug found is one less that the end-users will encounter.