ATE configurations are shared using various familiar formats, but many of the details are lost in translation.
In Test Capacity Management Chronicles, Part 1, I left off by talking about the industry shift to proactively managing tester configurations. I'm sure my story triggered memories of a similar season at your company when a more global assessment of your test configurations and capacity became essential to your survival. If so, how did you first start tracking your configurations back then? Maybe your experience and tool set was like mine described below.
Much like the case today, the test systems in the mid-1990s produced an electronic configuration file or "config file" that contained a rich set of detail on the hardware options in the system. The problem was that config files were readable by only a select few in the test community.
As a Field Product Specialist at Teradyne, I was trained to be one of those few. I spent a great deal of time manually checking and translating those files to not only ensure accurate alignment to system orders and device requirements, but to create readable summaries for sales, purchasing, and management. I also had to make sure important information not included in the config file made it into the orders, summaries, and the like. This work was performed using a variety of familiar formats like text files, spreadsheets, and presentation slides, but many of the details in the original config file were inevitably lost in translation.
While many loathed the config file, I embraced it. I considered it part of what allowed me to have "Specialist" in my title. More importantly, working with config files always provided an opportunity for geek humor by making the proverbial, but likely overused, "secret decoder ring" reference (see figure). I just did it again.
Config files, often written with text editors or spreadsheets, contain information on how ATE systems will be set up for a particular test.
Not everything was, however, done in a text editor. The most innovative related endeavor at the time was the internal development of a customer tester configuration manager in HTML, to be viewed on what was then a nascent Netscape browser. A clever solution for sure, but one that drove perhaps five page views per month, and really had just two unique visitors: I was one, with the other another test engineer in the office with a similar thing for configurations.
When I look back on those times, I don't really see much that has changed in the area of test capacity management tools and methodologies. The system config files are still esoteric and are complicated even further by the addition of floating feature licensing schemes. The tools used to document tester configurations have changed versions but are also largely the same. Unfortunately, there remains a loss of information and efficiency in the translation and communication process. Perhaps now is the time to bring back that web-based configuration manager!