It’s been a while since I read from Taiichi Ohno about the Toyota Production System and from Goldratt about the Theory of Constraints. Thus far I thought, both have close to nothing to do with each other. Today, however, I got an insight that brought the two closer together for me. Let me explain.

Some context

I am currently working on a client that deals with 6- or 7-joint robots, even in the industrial field. Today I worked with one of their teams on their product vision. They had identified customers as companies that want to automate portions of their work stream by bringing in a robot and teaching it some repetitive tasks, as well as users in those companies, people who teach the robot the movements it should start to do later on while working on several workpieces.

While coming up with value propositions, I brought up something I learned from Taiichi Ohno while he was setting up the Toyota Production System in the early 1950s and 1960s: automation with a human touch. Ohno argues that his goal never was to automate every step of a process, but maybe to make use of humans with creative brains aiding in automation.

I brought up how the robot can easily free the human brain from repetitive tasks in the work process, thus freeing the human brain from drought tasks. Instead, a trained craftsperson can inspect the workpieces that the robot has been working on and identify additional steps to apply maybe manually to finish off the coarse work that the robot easily repeated.

Theory of Constraints

As reflected in one of the wastes stemming from Lean, waste of human effort, it dawned on me, how this principle basically is applying Theory of Constraints Thinking to the problem of automation. Let me explain.

In the Theory of Constraints, every production process is limited by a constraint, the slowest or most time-consuming step in the production facility. The whole system cannot produce faster products than the constraint currently allows. Goldratt identifies five focusing steps to improve the system:

1. identify the system’s constraint(s): Identify the current constraint (the single part of the process that limits the rate at which the goal is achieved).
2. Decide how to exploit the system’s constraint(s): Make quick improvements to the throughput of the constraint using existing resources (i.e., make the most of what you have).
3. subordinate everything else to the above decision: Review all other activities in the process to ensure that they are aligned with and truly support the needs of the constraint.
4. elevate the system’s constraint(s): If the constraint still exists (i.e., it has not moved), consider what further actions can be taken to eliminate it from being the constraint. Normally, actions are continued at this step until the constraint has been “broken” (until it has moved somewhere else). In some cases, capital investment may be required.
5. Repeat the process: The Five Focusing Steps are a continuous improvement cycle. Therefore, once a constraint is resolved the next constraint should immediately be addressed. This step is a reminder to never become complacent – aggressively improve the current constraint…and then immediately move on to the next constraint.

(source of the explanations)

If the constraint in a production process is the creativity of a human crafter, one way to exploit, subordinate, and elevate that constraint lies in freeing the human mind from boring, repetitive tasks that break his creativity zone. So, if we bring in automation to free the human mind from the repetitive steps in that process, we make sure that the constraint of human creativity can be used to think about more problems.

Does this relate to test automation?

I think this point can be related to the benefits you can get from following a balanced approach between test automation and exploratory testing as well. Make sure to keep that human touch though. In software testing, usually, there is close to an infinite amount of tests that you could potentially run.

As Doug Hoffman explains in Exhausting your test options, he was tasked in his career once with testing the square root calculations of a new floating point unit. In order to make sure all input values resulted in the correct results for 32-bit floating point numbers as inputs, he precalculated on another device the expected results, automated all 4 billion calculations with the new calculation unit, and let it run on the new computer. Through the automation, the execution took 5 minutes. He found two erroneous results.

Thinking forward to 2022, we currently deal with 128-bit floating point numbers in more modern computers. Assuming the same execution times would yield 1^40 hours to calculate (several millennia). Thus, it’s impractical to test all the values on a modern computer, and just consider how more complex than calculating square roots modern applications have become. In fact, the whole software testing theory mainly deals with ways to reduce the number of tests that you execute to some meaningful subset of all the tests you could potentially run.

As the story also illustrates, Doug Hoffman used automation to aid in his testing with a human touch. If automation takes away the boring tasks from the human brain cells, we can spend more time exploring what our automation did not catch. I came to realize how this as well relates to Theory of Constraints Thinking applied to software testing. And I began to realize how the similarities in other places of work have similar constraints.

Then it dawned on me, that the whole fear about automation taking away jobs from folks, is more an emotional one rather than a logical one. But maybe we need to dive into that distinguishment at some other point in time..