For many years after DEFINE went live, the Accounting IT team worked to find and fix bugs in the system. These bugs occurred infrequently, but they resulted in inaccurate balances, which needed to be corrected through regular sweep jobs. When Cathy Lester started as Associate Director over Accounting IT in 2000, she decided it was time to investigate and fix these bugs at their root, rather than continue to fix them after the fact. Cathy put together a team of analysts that included Greg Atkinson, Louise Nelson, Cooper Henson, and Cathy herself to analyze and debug The Poster.

Made up of over 100 modules, the Poster was notoriously difficult to debug because the data cases that existed in production were hard to recreate in the test environment. The data simply was not present in TEST, and though there were utilities to roll accounting's records back from PROD to TEST, these utilities could not capture all of the data cases needed to replicate problems, since much of the data from HR, Appointments, Payroll, Budget, and other outside areas was not available in TEST.

The Poster team determined that the best way to find bugs was to use the Natural Debugger to follow the executing code through all the various modules step by step. However, since the data in TEST was incomplete, and following a transaction through all steps in PROD was a *really* bad idea, we realized we needed a non-production environment that had a complete set of production-quality data.

Cooper and Louise worked together to develop a business case for a new environment, which would be used not only for debugging, but also for testing code rigorously against high-quality data before moving it to production. Cathy brought the idea to the Administrative Computing Director, Randy Ebeling, and the DBA, Brick Jones. A key part of the proposal was the idea of regular, comprehensive, and coordinated refreshes of all files from all business areas of the University in the new environment. This would allow all data to look like prod, making it easier to reproduce difficult bugs and test systems that make calls across functional areas.

At a TXEDGE meeting on the proposed environment, Louise proposed calling the environment “QUAL,” for Quality Assurance. The community agreed to the proposal, with the stipulations that areas could opt out their files on a file-by-file basis, primarily during periods of active development. The community also settled on a refresh frequency of once a month, which allowed time for setting up and running complex test cases in the QUAL environment, but also ensured that complicated data problems from production could be brought back to QUAL fairly timely.

Brick was able to get the QUAL environment up and running in relatively short order by repurposing the defunct Y2K environment. And using the new QUAL environment, the Poster team was able to identify and fix almost all of the long-standing bugs in the transaction posting system.

In 2002, Juan Ortiz figured out a way to run web code against the QUAL environment, using on the beta.dp.utexas.edu machine, but pointing the BETA servers to the QUAL environment in DPUSER. For many years this was the workaround for a web version of qual, until finally the Systems Staff put in place qual.its.utexas.edu.

It is difficult to imagine debugging problems and testing code without the QUAL environment now.