A co-worker recently turned me on to the book, The Goal: A Process of Ongoing Improvement by Eli Goldratt and Jeff Cox. Turns out, I’d been exposed to the ideas in the book at least a year ago by my former manager, but I didn’t realize it at the time. Since reading that book, I’ve also devoured 2 of it’s several sequels. In them, I have learned about what I think might be a very powerful system for problem solving that is relevant to software testing. This post is will be the beginning of a series explaining my exploration of these ideas.
First, some background. The Goal was very popular when it first came out because it challenged the state of the art in manufacturing processes and cost-based accounting. Today, it’s regarded as part of the “origin story” for Agile. The book is written as a fictional novel that slyly introduces the key concepts of the Theory of Contraints (TOC) through the story of Alex Rogo, a manufacturing plant manager who must quickly turn his operations from losing money to making money, or else. Unable to make new significant investments or develop new products on the tight deadline, Alex is forced to do some deep and creative thinking about how to save thousands of jobs.
Through a chance encounter with a former colleague, Jonah, Alex learns to use The 5 Focusing Steps, a series of processes to help identify the biggest constraint in a system and figure out what to do about it. These concepts were somewhat revolutionary at the time and got a lot of attention in manufacturing circles and MBA programs. The steps are based on the concept that a chain is only as strong as it’s weakest link, and therefore strengthening any link other than the weakest one is wasteful; it will not improve the strength (or throughput) of the overall system. The Goal walks us brought Alex’s learning of the 5 steps and applying them to successive weak links in his factory. You can probably guess that things end up well enough in the end for Alex, or else the 5 Focusing Steps wouldn’t have been regarded as successful. But At the end of the book, Alex is left wondering how Jonah, a college physics professor with no background in manufacturing, could have possibly known so much about Alex’s situation.
The answer comes in Goldratt’s next book, It’s Not Luck. In this book, Goldratt formally introduces Jonah’s method as the “Thinking Processes” (TP). If, like most of the colleagues I have surveyed, you stop after The Goal, I believe you will miss the most valuable part of Goldratt’s work. TP is an exhaustive (and exhausting) step-by-step process for identifying the. Ingest constraint in a system, determining what to do about it, and determining how to go about making the change.
Goldratt presents TP with several examples as he continues Alex Rogo’s story, now the VP of a division of 3 different types of companies. Readers are treated to multiple examples of applying TP to a variety of problems both in personal life and business. Goldratt’s next book, Critical Chain continues the exploration, this time applying TP to project management.
So why are TOC and TP applicable to software testing?
First of all, testing is a process by which raw materials (code, features, test plans) are turned into finished results (shipped features). Inherent in any process is a certain amount of waste, and TOC and TP can help discover and eliminate the waste. Bottlenecks and constraints are another common characteristic of processes, and testing is no different. TOC/TP can help you figure out which bottleneck is the biggest, so you can focus all your efforts on that until it is no longer the biggest problem. For example, are you flooded with more features to test than you can handle? Are you sitting around waiting for code from partner teams to arrive?
Second, TOC/TP force you to think, and think deeply, about the processes around you. As software testers, we are quite accustomed to thinking deeply about the features we test, but honestly, how often do we put the same rigor around our own processes? We have good intuitions, of course, and I’m sure we’re all detecting little smells of problems here and there and tweaking them along the way (perhaps in our sprint retrospectives), but to what effect? How do we know for certain that our efforts are being applied correctly and on the biggest problems? When we are pressed for time, it’s easy to jump on the first optimization opportunity that comes along. TOC/TP shows us the danger of doing this. As we saw earlier, we might just be wastefully optimizing a link in the chain that is NOT the weakest. Sure, it might come in handy down the road, but if we aren’t careful, there may not be a “down the road” if we don’t focus correctly.
Finally, software testing is a constantly changing field, and TOC/TP not only embraces change, but it establishes change as a core principle. In order to survive and remain competitive, we must change and improve constantly or get left in the dust of our competitors. Some in our profession believe that standards are the future of software testing (e.g. ISO 29119), but that line of thinking is dangerous because it prevents us from thinking for ourselves and continuously improving. Rather than submit to a static set of practices, it is crucial that we as testers learn to think thoroughly through our test problems and processes in order to apply our focus in the most beneficial way possible for our customers and our organizations.
Don’t take my word for it. Test my theory. Follow along as I learn and experiment with TOC/TP as a tester. Succeed or fail, we’ll learn something together. My next few posts will describe the various tools introduced by TP with examples from a theoretical software testing operation.