Automated software testing is a mistake proofing (poka-yoke) solution for software development.
The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.
So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.
The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.
Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. Automated software testing tools are a huge help in preventing many errors from affecting customers.
It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.
Related: Combinatorial Testing for Software – Metrics and Software Development – Checklists in Software Development – Google testing blog – Hexawise software testing blog
[I'm not trying to quibble over semantics, but …]
I think your example is really a poka-yoke for the user input process, not the software development process. Unit testing would be more analogous to poka-yoke.
The automated testing I refer to above is unit and integration testing. Application code is not deployed to the production server if those tests show the code includes a bug that causes the test suite to fail.
Any process that prevents code with a bug (defined as a failing test) from being deployed when any type of tests fail I would see as poka-yoke.
Selenium is another good automated testing tool. Which could be seen as integration testing but also more (testing browser compatibility).
Pingback: Deming vs. Automated Software Testing – Machiel's Blog
John,
Thanks for this example. I am constantly looking for good poka yoke examples for office environments. I hadn’t thought of that one before.
Your point on the quality of the poka yoke is equally valid in any environment. The same is true of fixtures or other devices. The key is to combine it with continuous improvement and keep making the poka yoke better.
Jeff
Pingback: How small batches improve product development | Manufacturology
Pingback: Curious Cat Management Improvement Blog » Mistake Proofing Deployment of Software Code
Pingback: Curious Cat Management Improvement Blog » Annual Management Blog Review: Software, Manufacturing and Leandership
Pingback: Software Testing and the Impact on Quality » Curious Cat Management Improvement Blog