The Importance of Documentation


Documentation is the bread and butter of a QA engineer. We depend on it, and if it doesn't exist already, we may have to make it ourselves.

Specifications


Would you be surprised to hear that I've talked to more than one company who claimed they didn't have a specification for their product? Ridiculous, right? How did they know what to build?

Of course they *did* have a specification, kind of, although they didn't realize it. It wasn't formalized, and this led to real problems. Companies have a variety of ways to write specifications, even if they aren't called that. They may have Marketing Requirements Documents, Product Requirements Documents, End User Safety documents, kickoff meetings, or other processes that are used to decide how the product needs to work. Often the MRD and/or PRD are handed to an engineering team, who then writes a "technical spec" based on their mechanical and electrical capabilities.

Or maybe everyone just all sat around in a bar after work and verbally agreed on the product!

It is one of the QA Engineer's jobs to read all those documents, attend all those meetings, or otherwise extract the ideas out of the stakeholders, and distill them into testable requirements. Is the product going to be used outdoors? What tests will we need? It will need a display that is visible in full sunlight. It will need some amount of rain or splash resistance. It will need to have some resistance to being accidentally dropped.

A few more examples: Will the product be powered by "mains" electricity, from a plug in the wall? It will need a fuse or circuit breaker. If the chassis is metal, it needs to be connected to earth ground. If there are common or predictable failure modes, they should never result in the user contacting the full voltage.

All of this information needs to find its way into a document the QA engineer can use to test the product during development, before MP (mass production) and periodically during production. The tests should be labeled or linked back to the documents or meetings that generated them. Use cases are often good additions to make sure later changes to the test still meet the "spirit" of the original goal.

And what do we do with this document once we've assembled it? Well we keep it handy. It should be stored in document control, or version control, or on a wiki, or in a well-organized binder or file cabinet. You'll want to refer back to it if a test needs to change for some reason, or if requirements are added (or removed). Customers may want copies of it, or documents that can be easily derived from it.

If you have a good spec, you can literally change the entire product design and engineering behind the product, but keep on shipping a product that meets your (internal or external) customers' needs!

Comments

Post a Comment

Popular posts from this blog

The Boeing 737 MAX, a QA perspective

Image
Thanks to: Wikipedia.org user Acefitt The Boeing 737 MAX and its MCAS system (which tries to emulate the handling characteristics of earlier generations of the product) have been in the news a lot lately. Investigations are still ongoing, but the product is being blamed by many for two crashes which have resulted in the loss of almost 340 lives. That's a big quality problem. Clearly, the pressures on the Boeing are immense. The worldwide commercial aircraft market is over $191 billion , and dominated by cut-throat competition between Boeing and Airbus. The 737 has been in production since 1967, and if you are a pilot who was qualified to fly it in 1967, you still are today , despite vast numbers of changes to the aircraft. This is because Boeing has managed to keep the aircraft handling similar enough over time that the FAA (and other worldwide governmental authorities) has been willing to allow the "type certification" of pilots to be valid for all variants of t...
Read more

The risks of the "Golden" sample

Image
It's very tempting, and if you've ever worked with overseas contract manufacturers (CMs) they will almost prefer to use a "Golden Sample" instead of a detailed specification. Coyau /  Wikimedia Commons  /  CC BY-SA 3.0 In hardware manufacturing, it's easier to understand. I freely admit I've written incoming parts inspection instructions that don't have every detail of the part! Every dimension, the depth of any indentations, the gauge of any round protuberances, the color of all the materials, the hardness, even the chemical composition (important for fasteners and structural parts). If you simply take a prototype or early unit from the manufacturing line, give it a thorough inspection, and declare it to be a "Golden Sample," it's a heck of a shortcut, saving a lot of *your* time as the person who would otherwise have to write the documentation! There are risks, however, and you need to think about them, minimize them, and try to m...
Read more

Applicability of Economics to QA

Image
Years ago, I started listening to Russ Roberts' excellent podcast EconTalk ( http://www.econtalk.org ), and the more I've listened to it, the more I've come to understand that although the origins of economics and the study of quality may be different, the practice is very, very similar. What do we measure? We face a constant struggle trying to measure the right variables, and what is "right" changes over time. In economics, it seems like new indicators become popular all the time. After the Great Depression, the concept of a nation's Gross Domestic Product rose in popularity as economists worked on trying to explain how nations were affected by the depression, and how they might be able to avoid similar events in the future. However, GDP did nothing to predict the "Great Recession" of 2007-2009, and in fact trailed the crisis by a considerable time. We face similar issues with quality. Production or build test failure rates come to us p...
Read more