How did QA tell when a product failed its burn-in? The product stops working because its electronic circuits overheat and literally burn up. Everybody could tell where QA was located by the smoke rising above it from smoldering circuit boards.
Why you need to know where Smoke Tests fit in Your QMS
Robin F. Goldsmith | isoTracker Solutions Ltd
Everybody could tell immediately where QA was from anywhere on the vast factory floor. My client’s parent company’s name is synonymous with world-class quality; and this division’s high-tech electronics products were widely recognized within their industry as the standard of excellence.
Quality doesn’t just happen. It’s the result of conscious, informed decisions and actions. For my client, outstanding products were the result of constant attention to excellence at every point in the manufacturing process. Skilled engineers followed proven processes to design and manufacture great products. They used the best materials, manufacturing equipment, and processes for the job.
One Final Step
Yet, they knew that just following manufacturing processes which reliably produce high-quality products was not sufficient. Before a finished product could go out the door, it had to pass one final step—Quality Assurance (QA). In this organization, QA was responsible for “burn in.” Each product that had been manufactured was plugged into electric power and run non-stop for a specified period of time.
Burn-in duration varied by product based on engineering data measuring important characteristics of the various products’ components. The QA engineers knew that electronics have a very distinctive critical characteristic: they generally fail very quickly or run for a very long time.
Thus, QA burned-in each item by running it long enough for it to fail if it was going to fail right away. Only the products that would run without fail were shipped to customers. Burn-in not only confirmed adequacy of the manufacturing process, but it also assured customers received only products that would run reliably. Such reliable continued operation was one of many factors contributing to the products’ well-earned reputation for excellence.
How did QA tell when a product failed its burn-in? The product stops working because its electronic circuits overheat and literally burn up. Everybody could tell where QA was located by the smoke rising above it from smoldering circuit boards. Consequently, this technique also became known as a “smoke test.”
Manufacturing Smoke Tests and Your Quality Management System
In manufacturing, such smoke tests are essentially done at the end, right before passing products are packed and shipped to customers. Unlike earlier manufacturing processes that relied exclusively on final tests to assure quality, in an effective Quality Management System (QMS), smoke tests close the loop on a coordinated set of many procedures that build quality into the product throughout the entire manufacturing process.
At a minimum, a QMS should identify:
- the smoke test’s role and point in the overall manufacturing process;
- procedures, practices, and rules for performing it;
- records of smoke test results and related analysis and metrics; and
- routing of results for further analysis and corrective and preventive actions.
The QMS does not define these elements but rather prompts defining and keeping track of them, as well as assisting those performing relevant processes. For instance, frequency of product failure not only can be detected quickly but also can be related to likely causes for further investigation, such as engineering changes, equipment, and materials sources.
We Don’t Manufacture Electronics, Why Care about Smoke Tests?
As useful as smoke tests can be for electronics manufacturing, they may not seem to apply to making other types of products. That could be a serious misjudgment causing you to miss an important simple way to reduce waste while improving quality.
Software development seems about as far removed from manufacturing as could be. Yet, most smoke tests today occur in software development. Not only is software a critical element in many manufactured products, these are the smoke tests you’re most likely to benefit from emulating.
Recognize, though, that software development applies the term “smoke test” to situations which don’t resemble QA on the manufacturing floor. First, there’s not actual smoke with software; it’s just metaphorical. Second, software smoke tests occur far earlier and more frequently than manufacturing’s tail-end version. Third, failing a software smoke test doesn’t mean discarding the failing product.
Unlike tangible products, software is eminently modifiable throughout its development (i.e. manufacture). Software is developed by writing lines of code, where each line is an instruction to the computer. When a computer program fails to work properly, the developer analyzes the code until discovering the problem’s cause and then revises the code accordingly. Of course, the same process is followed to fix tangible products; but often tangible fixes are harder, take longer, or are less practical.
For software development, a QMS probably reflects a fairly predictable sequence which is often referred to as the “V model.” Going down the left side, development proceeds from defining business requirements, designing a high-level solution, driving that down to low-level design detail, and then implementing the design by building the product or some identifiable part of it. If you instead build tangible products, your process sequence is probably still very similar.
Then, going up the right-hand side of the “V,” each development artifact is tested as it’s created. Thus, unit tests are code-based and demonstrate the smallest pieces of executable code. Integration tests exercise combinations of pieces of code and especially focus on interfaces. System tests confirm all the pieces work together to accomplish the high-level design’s major features and functionality. User acceptance testing (UAT) matches what the development side of the house thought they should create to what the business needs. Again, an effective QMS for manufacturing tangible products applies similar testing at key points throughout.
So Where Are Software Smoke Tests?
Software developers usually are responsible for coding and unit testing their code. When different pieces of code are put together, it’s often called a “build” or “integration.” Typically builds are submitted to software QA/testing for independent integration testing. Before diving into extensive testing of a build, QA ordinarily first runs a smoke test to ascertain whether the build is stable enough to warrant further testing.
The software smoke test is not concerned with testing all the ins-and-outs of the code, only that main processing can run from beginning to end, not necessarily perfectly but without “burning up.” If “smoke” appears (that is, the smoke test fails), the code goes right back to the developers so QA doesn’t waste further time executing tests that would fail due to instability rather than from whatever the test was intended to show. By the way, smart developers run their own smoke tests so they only send stable builds to QA. That saves time and embarrassment.
Lessons for Manufacturing QMSs
No doubt some outside of software have figured out ways to apply software smoke test concepts, but surely additional opportunities remain. After all, software integration should be familiar to manufacturers. It’s where assemblies and sub-assemblies are put together; and they are good candidates for their own version of smoke tests (even though they may not actually smoke).
Robin F. Goldsmith, JD, who writes for isoTracker QMS software, works with business and project professionals to get right results right. His thought-leading concepts have influenced international standards on software acquisition and software quality assurance. He is author of “Discovering REAL business requirements for software project success” and the forthcoming “Cut Creep—Write right agile user stories and acceptance tests”.
The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow
Comments (0)
This post does not have any comments. Be the first to leave a comment below.
Featured Product
