Drawn up in the 1960’s by Shigeo Shingo, an industrial engineer at Toyota. Originally baka-yoke, meaning “fool-proofing” (though fool is the least offensive translation), but was later changed because offensive connotation to Poka-yoke mistake proofing .
It has no been applied to SDLC (Software developement life cycle).
Objective
Aims of Poka Yoke are help people and processes work right the first time, which makes mistakes impossible to happen.
Categories of Poka Yoke
- Defect Prevention - software requirements review used to identify all possible issues and actions needed to eliminate those issues.
- Defect Detection = detected testing methods like Smoke and Exploratory testing plus other strategies.
Both can be achieved in the domain of QA, however there scope for domain experts to identify issues in the design phase
Many software defects can be prevented in the design phase itself, by reviewing the Software Requirement Specification documents. All issues identified in this stage should be addressed in software coding phase and prevented from carrying to later stages.
Defect Detection is the most common task for quality assurance teams.
The Qualities of a Good Poka-Yoke Process?
As well as being simple to create and maintain Poke Yoke should meet the following criteria:
- It should be easy and cost-effective, if is complex then it is time-consuming ,difficult to maintain and often results in issues
- It should be part of the Software Design and Coding process, applied in the early stages to enable issues to detected and resolved quickly.
- will help to find issues when they occur.
- Should be designed in such a way that it should stop the most common issues occurring in the software.
Poka-Yoke In Software Design Phase
The Steps to Implement a Poka Yoke Process go through two sever stages
Design
- List all user scenarios or end-to-end test cases for the application.
- Analyze all these user scenarios by asking 5-whys questions to understand the ways these scenarios can fail.
Code
- Defensive coding using tools like intention revealing types, clear naming, enforced preconditions, easy to understand exceptions.
Test and rework
Test the software to see if design considerations meet and rework if defects not caught. This latter process will Embody Kaizen (continuous improvement process).