How testing deserves respect for a legacy of failing forward.
You’ve been there. Stuck in that post-mortem meeting to discuss the consequences of poor testing or no testing practices after being hit hard with a production failure or outage. It is tough being a tester in that room, knowing it’s not going to help anyone for you to blurt out the ‘I told you so’ jab to the project manager who cut testing time from the schedule. It’s even harder to hear an engineer sitting next to you proclaiming “failure is a good thing” and that “we should be failing sooner and more often.” Next time tell him this: “Excuse me, but that’s so ignorant.” Then tell them about the legacy of how testers have been advocating intentional, proactive failures for decades and decades. In fact, software testing is fundamentally the inventor of this idea of “failing forward.” Over the last fifty years we have developed incredible skills, methods and tools to efficiently and effectively induce failures to provide opportunities for learning, improvement and resilient recovery. You might almost say that as a software tester, you are an expert in failure.
But where did this the “failure fad” first get its mojo? Back in 2002 an article entitled “The IDEO Difference” was featured in the United Airline’s in-flight magazine Hemispheres. The article was a promotion of this now-famous company in Palo Alto, California; IDEO “an award-winning global design and innovation consultancy” as is now stated on its website. At the time IDEO was known for mostly industrial and commercial design and had nothing to do with software development or testing. Interestingly enough, there was a passage in the article attempting to describe failure as being at the core of the creative process. The author Catherine Fredman wrote: “…as an IDEO slogan puts it, ‘Fail often to succeed sooner.’ [Tom Kelley, IDEO founder] tells a story that illustrates the companywide willingness to ‘fail forward.’ An employee came back from his first-ever ski trip and boasted to his team at its Monday morning meeting that he had skied for three days and never fallen down. “He expected them to pat him on the back. Instead, people heckled him, saying, ‘If you didn’t fall down, you never pushed the envelope. You established a comfort zone and stayed in it.'”
Back when I was learning how to ski I was pretty happy when I completed a single run without falling, let alone an entire 3 day ski trip. The way you might understand that story is that the team was ambitiously creative about ideas and they are rewarded when they push each other “outside their comfort zone” in all things. But, in my own career I’ve never observed any increased creative productivity from peer heckling, intimidation and criticism. To some folks in Palo Alto, that’s just another part of working in the competitive high-tech rat race. The article also includes a quote from IDEO’s CEO Tim Brown as stating: “The discovery that Thomas Edison made is that you innovate by iterating quickly, by having lots of prototypes. Prototyping allows you to learn from risks almost immediately.”
IDEO was clearly not the genesis of this “failure fad” alone, but permissive failure as a part of prototyping and brainstorming was clearly a part of their operational philosophy back before 2002. More recently the testing community has been disrupted about Alberto Savoia and his proclamation that “test is dead” – posting blog entries and articles all over the testing web-o-sphere with rebuttal and dismissal of Alberto’s claim. As it turns out Alberto was just making a second-hand reference to the same prototyping (for Alberto it is “pretotyping”) evidenced in Thomas Edison’s ideas more than a century ago.
Let’s try to connect this all back to the idea that as a software tester you are most likely an expert in the craft of intentional failure. Certainly not in a legally binding definition of the word ‘expert’ – but relative to the experience of many developer or operations engineers around you, as a tester I would say you are in-touch with how to leverage failure to the benefit of your organization more than they are.
First, a very important benefit you bring as a tester is that you know how to fail sooner – before you release to production. Tests that intentionally force the application component into a failure state can sometimes be executed just a few minutes after the code is actually checked-in. Manual exploratory tests can be concurrently executed as the developer actively building and changing the code. You can’t get ‘sooner’ than that. Even with nightly builds and deployment to a QA environment, these test builds are prototypes which we purposefully cause to fail in order to learn and adapt.
Secondly, the other important expertise you bring as a tester is that you can fail more frequently by automating the testing processes. Testers can help increase the statistical calculations for the probability of failure through repeated, automated testing. Automated suites of failure-inducing test scripts enable testers to prioritize the manual and exploratory testing efforts to focus on more important or complex kinds of failures. Automated failure isolation and capture helps us to achieve maximum efficiency in failure examination and escalation for repair.
The popular philosophies about failure are not new. The philosophies about testing are not new, either. But testing has been helping to prevent failure for about as long as failure has been around. And causing intentional failure as a part of the prototyping process in order to reduce the risk of failure is at the core of testing’s definition. Failure due to a lack of testing is just plain ignorant, especially when we’ve gotten so good at it!
Editor’s Note: Mark Tomlinson has been contributing his thought leadership content to the STP Community for many years. His most recent project is as the co-host the new internet radio show PerfBytes at www.perfbytes.com. The tagline is “Helping IT Professionals To Improve Performance Practices”. I hope you check out his show and continue to receive value from his knowledge and expertise as an IT practitioner.
About the Author
Mark Tomlinson Mark Tomlinson is a software tester and test engineer. His career began in 1992 with a comprehensive two-year test for a life-critical transportation system, a project which piqued his interest for software testing, quality assurance, and test automation. That first test project sought to prevent trains from running into each other — and Mark has metaphorically been preventing “train wrecks” for his customers for the past 20 years. He has broad experience with real-world scenario testing of large and complex systems and is regarded as a leading expert in software testing automation with a specific emphasis on performance.
Mark worked for six years at Microsoft Corporation as a performance consultant and engineer in the Microsoft Services Labs, in the Enterprise Engineering Center and in the SQL Server labs. His efforts to foster the success of Microsoft’s top-tier Enterprise customers was focused on their early adoption of Microsoft products as part of mission-critical operations. In 2008, as the LoadRunner Product Manager at HP Software Mark led the team to deliver leading innovations for performance testing and engineering as part of HP’s suite of performance validation and management products.
Mark now offers coaching, training and consulting to help customers adopt modern performance testing and engineering strategies, practices and behaviors for better performing technology systems.