MOCM 8 ~ 2002 ome arco as a8 NT RD RANSLATIO! N Bee OTHER LANGUAGES Cristian VINTILA, Carol SCHNAKOVSZKY University of Bacau mi ngineer Shigeo Shingo. The aim of poka-yoke is to eliminate defe; sapere or eeecsiin mistakes as early as possible. Poka-yoke has most frequently in manufacturing environments. The currently develops its Desktop Environment software to run in twelve locales or languages. Traditional t this localized software is technically difficult and time-consuming. By introduc’ ‘yoke (mistake-proofing) into our software process, we have been able to prevent lite hundreds of software localization defects from reaching our customers. This describes the poka-yoke quality approach in general, as well as our particular us technique in our localization efforts, Poka-yoke is providing a simple, robust and pi ‘way for us to detect defects early in our localization efforts. 1, INTRODUCTION Poka-yoke (pronounced "POH-kah YOH-kay") [1] was invented by Shigeo Shingo in the I “poka-yoke" comes from the Japanese words “poka” (inadvertent mistake) and "yoke" n idea of poka-yoke is to design your process so that mistakes are impossible or at least ea corrected. Shigeo Shingo was a leading proponent of statistical process control in Japanese manuf became frustrated with the statistical approach as he realized that it would never reduce p 2, CATEGORIES OF POKA-YOKE DEVICES Poka-yoke devices fall into two major categories: prevention and detection. A prevention dey process so that itis impossible to make a mistake at all. A classic example of a prevention: a3.5 inch computer diskette, The diskette is carefully engineered to be slightly asymmetrical into the disk drive in any orientation other than the correct one. Prevention devices remove th mistake, since the user cannot make the mistake in the first place. A detection device signals the user when a mistake has been made, so problem. We are surrounded every day by both detection and prevention vain oon usually think of them as such. The microwave will not work if the door is open (a p beeps if I leave the key in the ignition (a detection device). At few years ago, some cars Were start until the passengers had buckled their set belts (a prevention device) but this mechame and was replaced by a warning beep (a detection device) 5 a 2. CHARACTERISTICS OF GOOD POKA-YOKE DEVICES Good poka-yoke devices, regardless oftheir implementation, share many common chara145 are simple and cheay they are part of the proce, 4S f° t00 complicated they are placed eyes implementing wha Sere Nw wl no be cos-teciv peri ls "100%" inspectior mistake aun rf 6S can be corrected stakes occur, providing quick feedback to the workers so that the 3 POKA-YOKE AND SOFTWARE QUALITY Being mainly a manufacturing teehn} development, but the philosaphy betged oe/OKe Bas only rarely been mentioned in connection with soft Gordon Schulmeyer (6) and James‘ yoke has never been far from the heart of soltware quality have championed detection and preversin cd TE 10 poka-yoke explicily, but many software quality daha Techniques [a “Weare mame ele Meds instvar In 190, Boke Sekar we purpose ~ bug prevention = it meh atari Be Bus, To the extent that quality assurance fale ots prises Kve a secondary goal of bug detection”. In 1993, Steve Maguire echoed 4 similar sentiment in Writing Solid Cade fons asking themselves two questions: oa 91 “Allof the techniques and guidelines are th result of programmers + How could I have automatically detected this + How could Thave prevented thstegh ne 3.1. Prevention devices in software 3.2. Detection devices in software Software testing is a form of detection device, but traditional system testing occurs too late in the process to allow quick, corrective feedback on mistakes. Unit testing and "smoke testing" (7] come closer to the notion of poka-yoke, in that they are located close to the source of the potential mistakes and the quick feedback they provide can keep mistakes from moving further along in the process. The tools in software that most closely resemble poka-yoke devices are the programs such as lint, printfck, cchk, clash [10] that examine the syntax of programs and alert the programmer to a possible mistake in need of correction. Static analysis utilities are simple and cheap to run; they aim to eliminate certain classes of common mistakes; and they concentrate on the syntax of the program rather than the program's function. Some of recent work in localizing software applications has illuminated areas that yield more readily to a poka~ voke approach than to traditional testing. The sections that follow describe our application of poka-yoke principles to solve a problem that defied a traditional software testing approach. 4. POKA-YOKE AND LOCALIZATION iant software in multiple locales, developers store locale-specific strings in files called To crear cone eee erat into tbe Sralicd, a developer stores the text string in the it by its message set and message number. ‘A message set and message number the catalog. Localization is the process of creating a message catalog for a particular language. iit is ically dor Localization is typically done after the development of ne “ge Be inioancete See means people external to the co ci euieaee ea ‘They then trans! late each message ae Sea i ee language. Localizing 8 srr Da ray ioe Tie ese ed te aevclorect familiar with the application. They may be } ‘ing. Usually, therefore, the localizer performs ormanizatiegy They may not even be familiar with programming. fsanthe contents of the message CalalOES andthe sansiations based almo: ty on the jocalization documentation. oftware 4.1, Testing localized s vique set of challenges. The localizers inom Wag Seplication run, they cannot know if she cages are supposed 10 say, Dut since the i the translated message actually if developers to work together, €s hhave seen th the translated me t know if that is w rs an calized software Po team knows what the target languages. they cannot Sftime and distance. itis dificult for localiz ing done in N lang : cs Peet do not offer much relief. Running the tests manually can there are N foreign locales to test. Testers become fatigued running the same test if ant aay way to test the message catalogs is as follows : ‘© the test team receives the translated message catalog from the localizer tthe test team installs the new message catalog ‘and executes the test plan in the: 2 Govious mistakes are referred back to-the localizer and incorporated into a later: This approach has several drawbac thing, image comparisons are not por cchange on the screen when moving 103 n ‘would be a maintenance nightmare. Testing stable across locales, ew locale. The al Fig. 1. Text Editor File menu in English and Romanian Yet some sort of testin necessary here are many g of localized software make " ie mistakes when creating a message catalog. A ioolleeeeae tie specify an application menu incorrectly ; inadvertently delete a message string specify an invalid data format specify an invalid conversion fc format ee to translate a message oe pase incorrectly due to lack of context Wve different causes and different effects on the software that m the sof that.MOCM 8 ~ 2002 147 Itis. however, possible to construct into some depth a Poka-yokes to count pth about the pokayoke we sean CCUM each ofthese mistake, Asan example, we will go to mistake 4.2, Of mice and menus roof the localized application menus Many software users navigate thro § h meni ariecuee users can invoke menu actions without «anes OMY their i es , clicking on the selections they want, But ‘mouse, by using menu mnemonics, ees locale mene in message cases LN nes 3-aNeH 2 Nou 30 pen degen 4 Deschidere 38 6 Save 6 Salvare ide te 8 Print 8. Imprimare Application menus are prime candidates for translation into various languaj How else can users unfamiliar with English know what options are being offered? And since we are famttg each menu label, we must also translate the mnemonic associated with each label. In the Romanian locale menu shown in Figure 1, for instance, the selection that open the file has the label "Deschidere", and the associated mnemonic "D". In their respective message catalogs, the English and Romanian menus appear as follows, Table 1 5, USING POKA-YOKE TO DETECT MENU DEFECTS 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 "Open to "Deschidere”. Since the test team was not fluent in the N target languages, we had to leave this aspect to the language experts, ‘ond aspect of the message catalogs was the structure, the syntax rules that a properly constructed target eae spe Llc content it would be possible for te test cam to verify the sructural aspects ofthe Shtalogs. A menu is made up of labels and associated mnemonics. Each memu, regardless ofits contents or is 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 . Each mnemonic must be a single character ie : 5 he ee rrnem cos eas, and canbe ised owen hat a men x constructed comet inthe target locale 5.1. Design decisions ‘There were several possibilities for how to m8 ram epee mnemonics automaticaly, given a list ofthe + Prevention deviee) Ho rae anak prevent mistake, but the problem af choosing good a in each meni te elo regured writing the progam would note us x benefi mnemoni gained.MOCM 8 ~ 2002 — oyogram that would prevent the 1a ve could write & Prt ld also prevent mistakes: Bil approac ough to detect and correct after monic ar gram to verify that the CROS=A provide a Pd run the programs on thls ta os tpach would provide Very quick fee Towever, since We are sill d )\ (Prevention device that did not meet the be minimal; incorrect mne in device) We could os bove. Our local nlogs to us. Thi a criteria, THIS Fer sending ths teat to support ea\Coomets age catalogs 1d forth with the loca at ay program to verify the mea Isai aaa afer they are returned t0 US ‘by the localizers, i ‘some of the above 5 efficient as alizers, but the detected errors are: point cl vali -yoke scripts were used to val for each menu, showing the locatior is shown in Figure 2 Several small poka- construct a small table in the menu, A typical layou! table, retrieve the mnemonics and labels ‘A small poka-yoke script would read the t aren rhe recieved suings against the established criteria noted bow, Bas car ie deer cach mnemonic was contained in its label. The script would ili 11, 17) and fetch the string stored at that location in 1 : label ipeation (11, 18) and fetch the string stored there ("New"); finally the ‘mnemonic "N* was contained in the label "New, ae mnemonic label location _location 1,17 1118 N 11,19 11, 20 ° One 11, 21 11, 22 1 Inchides 11, 23 11,24 s 1, 25 11, 26 A 11,27 11, 28 P 11, 29 11,30 c Fig. 2. Locations of mnemonics and labels for Text Editor Fi Al als atin ae invariant across locales, so it was a simple matter to run the ser le. An error message is printed f i eventually wrote a half-dozen such peaks ie 1o vey aveleg be 6, APPLICATION The pokacyoke serps were small Because the scripts concern ‘system to execute the application. menus, or image comparisons. We plus U1 foreign locales. Each local hey were easy 5 10 write; some were written i ed themselves only were written in unMOCM 8 ~ 2002 149 applications, The results a are likely o be eye-opening By creating the Motif Style in remonics that was not explicitly stated in on another ment. This arrangetment pessoas the mnemonic for "Italic* on one mena and for “Imprima” 0 localizer translated ree Fine as long as both labels kept the same mnemonic, "I". But when the muemonic-abel relationship om tena aloes” and change the mnemonic rom "Rt "I, broke in inter-menn depaheaeaa menu, We will eventually refine our poka-yoke scripts to include * _ No mnemonic location can be reused within an application the Ron CONCLUSIONS running the application. The poka-yoke approach provided le and robust localization mistakes that ‘ould have been dificult to dec through wsdiionl nem tung REFERENCES (1| John Grout, Mistake-Proofing Production. Cox School of Business, Southern Methodist University [2] Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-yoke System, Productivity Press [3] Shigeo Shingo, The Sayings of Shigeo Shingo: Key Strategies for Plant Improvement. Productivity Press [4] NKS/Factory Magazine, Poka-yoke: Improving Product Quality by Preventing Defects. Productivity Press [5] Richard Chase and Douglas M. Stewart, Mistake-Proofing: Designing Errors Out, Productivity Press (6] G Gordon Schulmeyer, Zero Defect Software. McGraw-Hill, Inc. |7| James Tierney, Eradicating mistakes in your software through poka yoke. MBC Video (S| Boris Beizer, Software Testing Techniques; 2nd-ed. Van Nostrand Reinhold, (9] Steve Maguire, Writing Solid Code, Microsoft Press 10] lan Darwin, Checking € Programs with Lint, O'Reilly & Associates