Page 244 -

CHAPTER 8 SOFTWARE QUALITY ASSURANCE 215

ple, the ignition switch for an automobile will not work if an automatic transmission
is in gear (a prevention device); an auto’s warning beep will sound if the seat belts are
not buckled (a detection device).
An effective poka-yoke device exhibits a set of common characteristics:
• It is simple and cheap. If a device is too complicated or expensive, it will
WebRef not be cost effective.
A comprehensive collection
of poka-yoke resources can • It is part of the process. That is, the poka-yoke device is integrated into an
be obtained at engineering activity.
www.campbell.berry.
edu/faculty/jgrout/ • It is located near the process task where the mistakes occur. Thus, it
pokayoke.shtml provides rapid feedback and error correction.
Although poka-yoke was originally developed for use in “zero quality control”
[SHI86] for manufactured hardware, it can be adapted for use in software engineer-
ing. To illustrate, we consider the following problem [ROB97]:

A software products company sells application software to an international market. The
pull-down menus and associated mnemonics provided with each application must reflect
the local language. For example, the English language menu item for “Close” has the
mnemonic “C” associated with it. When the application is sold in a French-speaking coun-
try, the same menu item is “Fermer” with the mnemonic “F.” To implement the appropriate
menu entry for each locale, a “localizer” (a person conversant in the local language and
terminology) translates the menus accordingly. The problem is to ensure that (1) each menu
entry (there can be hundreds) conforms to appropriate standards and that there are no con-
flicts, regardless of the language that is used.

The use of poka-yoke for testing various application menus implemented in different
languages as just described is discussed in a paper by Harry Robinson [ROB97]: 5
We first decided to break the menu testing problem down into parts that we could solve.
Our first advance on the problem was to understand that there were two separate aspects
to the message catalogs. There was the content aspect: the simple text translations, such
as changing "Close" to "Fermer." Since the test team was not fluent in the 11 target lan-
guages, we had to leave this aspect to the language experts.
The second aspect of the message catalogs was the structure, the syntax rules that a
properly constructed target catalog must obey. Unlike content, it would be possible for the
test team to verify the structural aspects of the catalogs.
As an example of what is meant by structure, consider the labels and mnemonics of an
application menu. A menu is made up of labels and associated mnemonics. Each menu, regard-
less of its contents or its locale, must obey the following rules listed in the Motif Style Guide:
• Each mnemonic must be contained in its associated label
• Each mnemonic must be unique within the menu

5 The paragraphs that follow have been excerpted (with minor editing) from [ROB97] with the per-
mission of the author.