|
|
|
|
|
|
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. But it is 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
March 8th, 2010 at 11:16 pm
[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.
March 9th, 2010 at 9:09 am
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).
March 9th, 2010 at 10:38 am
[...] Hunter says tests are a form of prevention. They are a form of Poke Yoke, Poke Yoke means [...]
March 12th, 2010 at 10:31 am
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
March 13th, 2010 at 9:00 pm
“A couple of recent blog posts are representative: Hunter talks about how automated testing improves quality since it acts as a mistake proofing or poka yoke… automated testing of a product that is composed of ready–tested and reliable modules facilitates that developers make very frequent deliveries of small batches of working code.”
May 19th, 2010 at 11:20 am
[...] is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – [...]