With the rapid pace of product development today, we are all tempted to take shortcuts to get the product to market sooner than our competition. One hopes that the shortcuts taken during manufacturing test do not result in a two-million-unit recall. Some of the shortcuts don’t seem obvious or deliberate.
Take using a production BIOS for platform initialization as an example. This practice is used often to launch a test application after the operating system has booted. Assumptions made about the BIOS are likely to be that all the devices are initialized properly or the device driver loaded correctly. Can these assumptions impact production test? What if there were failures in the initialization? The assumption is, there are messages printed to the console. Are we certain? We assume that the console device initialized. What about the blank screen or blue screen; then what? Should we rely on the BIOS for manufacturing test setups? Does the BIOS design provide for a boot-at-all-costs implementation? If so, what might be marginalized within the platform that would impact test?
A better approach would be to have an independent platform/device initialization, with detailed diagnostic messages, rather than rely on a production BIOS. I’m not suggesting that test engineers become BIOS developers and deal with all the requirements of EFI. However, it is possible, with the correct tools, to model the BIOS behavior and provide for correct and independent platform initialization under full control of the test engineers. Rather than dive deeper into the topic here, I suggest reading the eBook "Testing Memories without BIOS on the Latest Intel Platforms" for more insight into the challenges associated with using BIOS as part of the manufacturing test strategy.
Remember: Failures in the field can and often are a result of assumptions.
