Poka-Yoke and Shift Left….. are they the same?

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]:

• 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)

The new procedure completely eliminated the problem of the missing spring’s thereby improving the reputation of the supplier, reducing cost and time and increasing product quality, all of the competertive advantages that we as an organisation are looking to deliver to our clients!!!
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.

Poka-yoke and Software Quality

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?

Prevention devices in software

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

Century Gothic - Do Your Bit for the Earth!

Use An Eco-Friendly Font! It consumes 30% less ink than “Arial”, the most commonly used default font.

Helping out nature can start with something as simple as using century gothic font in all your emails and documents which needs to be printed. It has been proven that Century Gothic uses 30% lesser ink than Arial - the default and widely used font. Though there are other eco-friendly fonts available out there, Century Gothic is the most economical as its free and readily available by default on all computers. Since Century Gothic has a thinner print line, it trumps all the other fonts when coming to saving ink and toner. I would discourage the use of printing documents unnecessarily. Help reduce our carbon footprint, print documents only if needed and use Century Gothic or similar eco-friendly fonts to do your bit for nature.

And it looks ok as well - Except not supported in this "Blogger" application!!!

Lean Testing & Early Waste Removal – is it a fantasy?

As you have started to read this I will assume that you are interested in testing and familiar with the "V" model. There are others [iterative, incremental, Agile etc] but for the purposes of this article I will use the terminology and methodology that is common.

Let's start with a common misconception:

Testing is easy and anyone can do it!!!

If that is the case why do we have lots of independent testing companies (large & small) and global system integrators all extolling the virtues of independent software testing, the numbers of skilled / certified resources they have and how they can save you money by adopting their processes and methodologies.

There are hundreds of reasons why testing is not easy, including but not limited to:

• Systems are increasingly more complex, more complex code, more complex integrations, and more complex business solutions.
  
• It takes skilled testing resources with the right training and application of experience to do well.
  

You will of no doubt heard or seen from one of the independent testing companies (large or small) that by removing defects early in the life cycle (left hand side of the "V" model), bottom line costs can be reduced; cycle times cut, defect leakage improved.

The rates of improvement, be it £, € or time vary but they all agree, applying lean practices and removing waste early in the lifecycle is good.

So if it is not a fantasy, how do we do it?

Well you could be forgiven for thinking that you just apply the following and hey presto all will be fine:

• Reviews
  
  • Inspections
    
  • Walk thoughts
    
  • Peer reviews
    
• Measurement
  
  • Dashboards
    
  • Balanced Score Cards
    
• Techniques
  
  • Risk Based Testing
    
  • etc
    

But alas it is not that simple. I'm going to use an analogy of driving a car to a destination in order to explain.

You need to know where you are on the map. If you are in a car and you don't know where you are a map or a list of step by step direction will not help!

You can use an assessment method such as TMMi (www.tmmifoundation.org) for this but as long as you know where you are you have a starting point. Before someone shouts, cars that are fitted with satellite navigation will show you where you are based upon your GPS position, I accept that and the navigation pinpointing where you are is analogous with the assessment above!!

So you now know where you are, but where do you want to go? What is your destination? It's the same as identifying your destination on the map.

Now this is where it starts to get complicated. What if your destination is different to the rest of the organisations, you as the tester / testing manager may want to go to a different place to the development manager, business sponsor or the business user.

Destinations can be based upon many things such as:

• Business domains
  
  • Safety critical,
    
  • Government,
    
  • Retail etc
    
• Business products
  
  • What is being sold to whom
    
• Risk appetites
  
  • Agile organisation vs. Non Agile
    
  • etc
    

Suffice to say, if the destination or goal can't be agreed on, the directions will fail, the organisation will not reach a common goal and waste removal will continue to be a fantasy and you won't be able to make the difference that is always extolled in the sales presentations.

It has to be a collaborative destination. "Share the Goal"

So now you know where you are and you have a common destination, what route are you going to take? Do you want to take the fastest route possible, motorways and dual carriageways or is travel economy more important, what about getting the best miles per gallon (MPG) on the journey or it could even be a balance of the two extremes.

Every journey for every company / team is different. Everyone starts at a slightly different points and not everyone wants to or needs to get to the same destination.

What is the risk to the journey?

• What is the risk of not making it to the destination? Failure
  
• What is the impact of not making it to the destination? Cost of failure
  
• What is the risk of arriving at the destination late?
  
• What is the impact of late arrival?
  
• What is the risk of changing direction once on the journey?
  
• What is the risk of changing the destination?
  
• What is the risk of an accident on the way?
  
• What is the risk of not taking the correct passengers with you?
  

These risks need to be managed, just as you would in a car journey:

• Split your route up into stretches
  
• Plan and announce your arrival time
  
• Plan your rest stops along the journey
  
• Prepare your vehicle for the journey ahead
  
  • Washer bottle
    
  • Fuel etc
    
• Check your route against known diversions or delays
  
• Take a phone along to advise of delays or changes of plan
  

It's then a case of starting out on the journey; following the directions and monitoring the road signs to ensure compliance to the map and directions to ensure you are still on the right road.

As with any long journey, you would not undertake the journey without planning to take regular breaks, rest stops, the same is true for organisational journeys, don't try and change it all at once, start at a project level, do one project or a few at a time (depends on how many change agents you have available) then move on to the next leg of the journey. Once you complete your first leg of the journey let your passengers know; highlight the success before starting the next stretch of the journey.

So you are now on your journey, don't forget to collaborate, you are not the only driver on the road, it has to be a collaboration between all parties; it is as much to do with relationships as it is to do with process. Failure to collaborate will result in a crash and once again waste removal will continue to be a fantasy and you won't be able to make the difference that is always extolled in the sales presentations. Lack of collaboration, arguments and disagreements along the way are natural, but lose concentration on the journey and the agreed destination and you will crash.

In conclusion: Lean testing is not a fantasy, but you have to navigate the route very carefully, understand where you are starting from, decide where you want to go, explore the route options (Motorway, Dual Carriage, A / B roads) to ensure that you get the required value (MPG), ensure you are taking the right passengers on the way to reach your destination at the correct date and time for your organisation.

Wow......... Thumbs up to Sky

Sky, they can do customer service, just replaced my HD box, again...... free. It pays to be nice to the contact centre advisers :-)

I called them on Sunday morning, they set an appointment date / time, arrived when expected and sorted. No fuss, no hassle. I wish all customer services could be like this.