The Binder and the Application

Twelve years ago when I started testing in the store systems lab at Limited Brands, we relied on the printed page to conduct our tests. Our scripts, or step by step instructions for specific business scenarios, were written in MS Word. They started with 1. Boot up the server and ended with 101. Shut down the server. The scripts were kept in large binders above the machines and when we needed to run a scenario or group of them, we got the binder down, turned to the page and started. This was as manual and functional as it get's I suppose.

At the time we were testing or supporting about 8 different brands such as Victoria Secret, Bath & Body Works, Express and the Limited. Each brand had its own binder. When a new scenario was needed for the brand, one of the team would create a new script in word, print it out and place it in the binder. After a while, these binders would accumulate notes and edits right on the page. These changes would take place in our down time. Early in our maturity we were not capturing actual results or marking the scripts when something unexpected occurred. After time, we began to see the need to keep testing proof of results (SOX), track our defects by system/tester/script, and assign the executed script to a specific project even if it was basic regression testing. At that time we assigned the script a unique id (such as VSS A.1) and on a cover sheet mark the system we were using, who was testing, the date - etc. That one page would be used to track results and end up in a big file box as a project artifact.

Obviously, in this testing organization we did not have a separate testing application such as Mercury/HP Quality Center. But, the way things developed in this primitive setting taught me much about Quality Center and prepared me to understand it in a basic way. For example in Quality Center you have the module Test Plan where the scripts are written and edited. This is comparable to the Word or Excel documented script. In the QC module Test Lab, the scripts are assigned an environment, a tester, a test phase and notes from execution are captured. This is comparable to the printed out version of the script or the cover page we created.

As the team matured, a few things took place. First we came up with a basic set of scripts that were applicable to all the brands. These were basic things that had to occur at the store - or critical to quality (CTQ) items - such as sales can be rung up. Then brand specific scripts were put into sections. So you would finish base section A, then insert brand specific section B, then move onto base section C. Secondly, the Word script became an Excel script. This made it easier to move or reuse components or sections of scripts to be used across brands (think future automation opportunities). Also Excel became an excellent tool for verifying calculations.

Excel is an amazing application. One of my colleagues and I spend 3 months of holiday down time recreating the base script in Excel. We were able to recreate the store and the management calculations which targeted some inconsistencies in how tax was calculated. The NCR registers rounded in a different way for tax that the management's reports were. A small thing, but multiplied by 200 stores or 300 days in the years, a significant delta. There was some complex retail math involved in other areas such as store productivity reporting and Excel helped us validate our results when combined at a regional level. Mainly the Excel script writing helped us get the company ready and focused for future efforts towards test automation work.