MISTAKE PROOFING FOR SOFTWARE

If William Shakespeare had commented on the modern software engineer's condition, he might have written: "To err is human, to find the error quickly and correct it is divine." In the 1960s, a Japanese industrial engineer, Shigeo Shingo , working at Toyota, developed a quality assurance technique that led to the prevention and/or early correction of errors in the manufacturing process.

Called poka-yoka (mistake-proofing), Shingo's concept makes use of poka-yoke devices—mechanisms that lead to (1) the prevention of a potential quality problem before it occurs or 0) the rapid detection of quality problems if they are introduced. We encounter poka-yoke devices in our everyday lives (even if we are unaware of the concept). For example, 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).

This approach is analogous to the risk analysis approach described for software project management . The primary difference is the emphasis on technology issues as opposed to project-related topics.

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 not be cost effective.

• It is part of the process. That is, the poka-yoke device is integrated into an engineering activity.

• It is located near the process task where the mistakes occur. Thus, it 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 engineering. To illustrate, we consider the following problem :

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 country, 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 conflicts, 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 .

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 languages, 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, regardless 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

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

• Each mnemonic must be a single character

• Each mnemonic must be in ASCII

These rules are invariant across locales, and can be used to verify that a menu is constructed correctly in the target locale.

There were several possibilities for how to mistake-proof the menu mnemonics:

Prevention device. We could write a program to generate mnemonics automatically, given a list of the labels in each menu. This approach would prevent mistakes, but the problem of choosing a good mnemonic is difficult and the effort required to write the program would not be justified by the benefit gained.

Prevention device. We could write a program that would prevent the localizer from choosing mnemonics that did not meet the criteria. This approach would also prevent mistakes, but the benefit gained would be minimal; incorrect mnemonics are easy enough to detect and correct after they occur.

Detection device. We could provide a program to verify that the chosen menu labels and mnemonics meet the criteria above. Our localizers could run the programs on their translated message catalogs before sending the catalogs to us. This approach would provide very quick feedback on mistakes, and it is likely as a future step.

Detection device. We could write a program to verify the menu labels and mnemonics, and run the program on message catalogs after they are returned to us by the localizers. This approach is the path we are currently taking. It is not as efficient as some of the above methods, and it can require communication back and forth with the localizers, but the detected errors are still easy to correct at this

point.

Several small poka-yoke scripts were used as poka-yoke devices to validate the structural aspects of the menus. A small poka-yoke script would read the table, retrieve the mnemonics and labels from the message catalog, and compare the retrieved strings against the established criteria noted above.

The poka-yoke scripts were small (roughly 100 lines), easy to write (some were written in under an hour) and easy to run. We ran our poka-yoke scripts against 16 applications in the default English locale plus 11 foreign locales. Each locale contained 100 menus, for a total of 1200 menus.

The poka-yoke devices found 311 mistakes in menus and mnemonics. Few of the problems we uncovered were earth-shattering, but in total they would have amounted to a large annoyance in testing and running our localized applications.

This example depicts a poka-yoke device that has been integrated into software engineering testing activity. The poka-yoke technique can be applied at the design, code, and testing levels and provides an effective quality assurance filter.

Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)