Poka-yoke [7] is a
quality assurance technique developed by Japanese manufacturing engineer Shigeo
Shingo. The aim of poka-yoke is to eliminate defects in a product by preventing
or correcting mistakes as early as possible.
Poka-yoke has been used most frequently in manufacturing environments but as the software development industry matures and QE&A matures we are becoming more and more akin to the mature product manufacturing systems that have been developed over the last few decades.
History
Poka-yoke (pronounced “POH-kah YOH-kay”) [1] was invented by Shigeo Shingo in the 1960s. The
term “poka-yoke” comes from the Japanese words “poka” (inadvertent mistake) and “yoke” (prevent) [2] and does what it says on the tin, implements processes or solutions to prevent small inadvertent mistakes or correct them ASAP after the mistake has been made.
Shigeo Shingo was a leading user of statistical process control in Japanese manufacturing industry of the 1950s and became frustrated with the statistical approach as he realised that the manufacturing industry would never reduce product defects to zero using statistics alone.
While visiting a plant in the early 1960’, Shingo came aware of a problem that the factory had with one of its products. Part of the product was a small switch with two push-buttons supported by two springs. Occasionally, the worker building the switch would forget (inadvertent mistake) to insert a spring under one of the push-button. Sometimes the error would not be discovered until the unit reached a customer, and the factory would have to dispatch an engineer to the customer site to disassemble the switch, insert the missing spring, and re-assemble the switch. This problem of the missing spring was both costly and embarrassing to the supplier and had a major impact on their reputation.
Shingo suggested a solution that became the first poka-yoke preventative process [3]:
Shingo made one crucial distinction between a mistake and a defect. Mistakes are inevitable; people are human and cannot be expected to concentrate all the time on the work in front of them or to understand completely the instructions they are given. Defects result from allowing a mistake to reach the customer, and defects are entirely avoidable. These concepts have been enshrined in future testing standards such as BS7925-1 Software Testing Glossary and the ISTQB Foundation certificate and the future ISO29119
standard.
Categories of poka-yoke processes
Poka-yoke processes fall into two major categories: prevention and detection.
A prevention process amends the product manufacturing process so that it is impossible to make a mistake at all. Prevention processes remove the need to correct a mistake, since the user cannot make the mistake in the first place.
A detection process signals the user when a mistake has been made, so that the user can quickly correct the problem (Early defect detection). The small dish used at the plant was a detection process; it alerted the worker when a spring had been forgotten. Detection processes typically warn the user of a problem, they do not enforce the solution.
Characteristics of good poka-yoke processes
Being mainly a manufacturing technique, poka-yoke has only rarely been mentioned in connection with software development, but the philosophy behind poka-yoke has never been far from the heart of software quality. Many software quality authors as well as standard bodies (ISO, BS etc.) have championed detection and prevention methods in software.
In 1990, Boris Beizer wrote in Software Testing Techniques [4]:
“We are human and there will be bugs. To the extent that quality assurance fails at its primary purpose — bug prevention — it must achieve a secondary goal of bug detection.”
In 1993, Steve Maguire echoed a similar sentiment in Writing Solid Code [5]:
All of the techniques and guidelines presented in this book are the result of programmers asking themselves two questions …
From a poka-yoke perspective, the development of computer languages could be viewed as a prevention device, since one objective of these languages is to prevent us from creating code that can be error-prone. High level languages prevent self-modifying code. Structured programming rescues us from spaghetti code. Object-oriented programming keeps us from stepping on each other’s data.
Detection devices in software
Traditional Software Testing is a form of detection process, but traditional system testing and beyond phases occur far too late in the product quality process to allow quick, corrective feedback on mistakes. Component testing and “smoke testing” [6] 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.
Are they the same???
So having established that the principles are very similar to Shift Left activities……… lets not re-invent the wheel
1. How can we better use these Poka-Yoke techniques more in End to End QA?
2. How can we better utilise the concepts of Poka-yoke processes in the future to improve what we are delivering to our clients?
3. How can we use the above story to highlight to clients the concepts of Defect Prevention and Early Defect Detection vs Traditional Quality Assurance / Testing
I am really interested in your experiences or thoughts on how we can re-use the concepts of simple changes to improve a clients business products…………
References
[1] John Grout, Mistake-Proofing Production.
[2] Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-yoke System.
[3] Shigeo Shingo, The Sayings of Shigeo Shingo: Key Strategies for Plant Improvement.
[4] Boris Beizer, Software Testing Techniques, 2nd ed.
[5] Steve Maguire, Writing Solid Code.
[6] James Tierney, Eradicating mistakes in your software through poka yoke.
[7] Wikipedia, Poka-yoke
Poka-yoke has been used most frequently in manufacturing environments but as the software development industry matures and QE&A matures we are becoming more and more akin to the mature product manufacturing systems that have been developed over the last few decades.
History
Poka-yoke (pronounced “POH-kah YOH-kay”) [1] was invented by Shigeo Shingo in the 1960s. The
term “poka-yoke” comes from the Japanese words “poka” (inadvertent mistake) and “yoke” (prevent) [2] and does what it says on the tin, implements processes or solutions to prevent small inadvertent mistakes or correct them ASAP after the mistake has been made.
Shigeo Shingo was a leading user of statistical process control in Japanese manufacturing industry of the 1950s and became frustrated with the statistical approach as he realised that the manufacturing industry would never reduce product defects to zero using statistics alone.
While visiting a plant in the early 1960’, Shingo came aware of a problem that the factory had with one of its products. Part of the product was a small switch with two push-buttons supported by two springs. Occasionally, the worker building the switch would forget (inadvertent mistake) to insert a spring under one of the push-button. Sometimes the error would not be discovered until the unit reached a customer, and the factory would have to dispatch an engineer to the customer site to disassemble the switch, insert the missing spring, and re-assemble the switch. This problem of the missing spring was both costly and embarrassing to the supplier and had a major impact on their reputation.
Shingo suggested a solution that became the first poka-yoke preventative process [3]:
- In the old method, a worker began by taking two springs out of a large parts box and then assembling a switch.
- In the new approach, a small dish is placed in front of the parts box and the worker’s first task is to take two springs out of the box and place them on the dish. Then the worker assembles the switch. If any spring remains on the dish, then the worker knows that he or she has forgotten to insert the spring. (Preventative)
Shingo made one crucial distinction between a mistake and a defect. Mistakes are inevitable; people are human and cannot be expected to concentrate all the time on the work in front of them or to understand completely the instructions they are given. Defects result from allowing a mistake to reach the customer, and defects are entirely avoidable. These concepts have been enshrined in future testing standards such as BS7925-1 Software Testing Glossary and the ISTQB Foundation certificate and the future ISO29119
standard.
Categories of poka-yoke processes
Poka-yoke processes fall into two major categories: prevention and detection.
A prevention process amends the product manufacturing process so that it is impossible to make a mistake at all. Prevention processes remove the need to correct a mistake, since the user cannot make the mistake in the first place.
A detection process signals the user when a mistake has been made, so that the user can quickly correct the problem (Early defect detection). The small dish used at the plant was a detection process; it alerted the worker when a spring had been forgotten. Detection processes typically warn the user of a problem, they do not enforce the solution.
Characteristics of good poka-yoke processes
- They are simple and cheap. If they are too complicated or expensive, their use will not be cost-effective.
- They are part of the product delivery process, implementing what Shingo calls “100%” inspection.
- They are placed close to where the mistakes occur, providing quick feedback to the workers so that the mistakes can be corrected.
Being mainly a manufacturing technique, poka-yoke has only rarely been mentioned in connection with software development, but the philosophy behind poka-yoke has never been far from the heart of software quality. Many software quality authors as well as standard bodies (ISO, BS etc.) have championed detection and prevention methods in software.
In 1990, Boris Beizer wrote in Software Testing Techniques [4]:
“We are human and there will be bugs. To the extent that quality assurance fails at its primary purpose — bug prevention — it must achieve a secondary goal of bug detection.”
In 1993, Steve Maguire echoed a similar sentiment in Writing Solid Code [5]:
All of the techniques and guidelines presented in this book are the result of programmers asking themselves two questions …
- How could I have automatically detected this bug?
- How could I have prevented this bug?
From a poka-yoke perspective, the development of computer languages could be viewed as a prevention device, since one objective of these languages is to prevent us from creating code that can be error-prone. High level languages prevent self-modifying code. Structured programming rescues us from spaghetti code. Object-oriented programming keeps us from stepping on each other’s data.
Detection devices in software
Traditional Software Testing is a form of detection process, but traditional system testing and beyond phases occur far too late in the product quality process to allow quick, corrective feedback on mistakes. Component testing and “smoke testing” [6] 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.
Are they the same???
So having established that the principles are very similar to Shift Left activities……… lets not re-invent the wheel
1. How can we better use these Poka-Yoke techniques more in End to End QA?
2. How can we better utilise the concepts of Poka-yoke processes in the future to improve what we are delivering to our clients?
3. How can we use the above story to highlight to clients the concepts of Defect Prevention and Early Defect Detection vs Traditional Quality Assurance / Testing
I am really interested in your experiences or thoughts on how we can re-use the concepts of simple changes to improve a clients business products…………
References
[1] John Grout, Mistake-Proofing Production.
[2] Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-yoke System.
[3] Shigeo Shingo, The Sayings of Shigeo Shingo: Key Strategies for Plant Improvement.
[4] Boris Beizer, Software Testing Techniques, 2nd ed.
[5] Steve Maguire, Writing Solid Code.
[6] James Tierney, Eradicating mistakes in your software through poka yoke.
[7] Wikipedia, Poka-yoke
I simply wanted to write down a quick word to say thanks to you for those wonderful tips and hints you are showing on this site.… I love to read your Software QA services articles because your writing style is too good, its is very helpful for all of us and I never get bored while reading your article because, they are becomes a more and more interesting from the starting lines until the end.
ReplyDelete