A Journey Through the Theory of Constraints

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.

On Context-Driven Testing

I may be the last person to learn about context-driven testing, but since I have recently, I felt compelled to share a few thoughts.

The concept of context-driven testing is described thoroughly by its creators, but at least part of it could be summed up quickly as “use the right tool for the job at hand.” 

For many, CDT may be one of those frustratingly obvious learnings that’s been sitting in front of you all along, hidden behind tradition and “best practices”.  We write test plans using the same template we’ve always used, hold the same meetings we’re used to holding, and assume that all new tests will simply plug into existing harnesses or test case managers. We get so used to “the way things are done around here” that we often forget to step back and just solve the problem at hand.

As I reflect back on the testers I’ve worked with over the years, I realized that while a significant number of them were brilliant when it came to testing software, many had not really tested their own processes.  They thrived in the momentum of their environment, but over time as new challenges came up, they had a tough time creating different kinds of momentum that were more applicable to the problem at hand (and I could draw parallels to “kids today”, but I’ll hold off for now).

My call to action for testers today is to pick at least one regular process you follow and seriously think about whether it solves a problem you actually have.  If you don’t know what problem it solves, ask a peer or your manager.  There’s a good chance that much of what you do is actually necessary – and in those cases you should definitely understand why!  But there’s also a good chance that at least some of what you do is just done because that’s the way it was done before you got there.  You read a wiki, followed a template, check, check, check, and off you went.  Be the person to spot one of these, and for bonus points, come up with a better way to do it – or cut it out altogether!