Add ‘all’ to questions

Alice was crossing the street, lost in her iPod, unaware of traffic. Bob was in his Toyota Prius driving towards Alice. Unknown to both of them, the traffic signal had a bug causing the walk sign to overlap ever so slightly with the end of the green light. Bob saw Alice and slammed the brakes. Unfortunately, the Prius’ braking system had a bug. Bob’s car hit Alice.

  • What caused this accident?
  • Whose fault is it?
  • Where can we improve?

Takeaway: Consider adding the word ‘all’ to some of your questions.
When to use?: As always, it depends. I use this tactic when we have multiple teams collaborating and I want to stress collective responsibility, improve teamwork, improve postmortems, etc.

add_all

Failure in complex systems are rarely caused in only one place. Almost always, when a complex system fails, more than one person caused the failure and more than one person could have prevented the failure. And yet, in many software projects, we hear questions like:

  • What caused this?
  • Whose fault is it?
  • Where can we improve?

Consider adding all to the above questions. It is a powerful way to change the way your colleagues will look at bugs and learn more from every failure. E.g.:

  • What all caused this?
  • Whose all fault is it?
  • Where all can we improve?

Adding all to your question is a powerful way to re-frame a problem and hint at multiple solutions. I have found adding all to some of my questions does wonders. It makes it easier to discuss mistakes, increases introspection in the team, reduces finger pointing during postmortems, improves company culture, anchors the context that we are all responsible and increases a sense of ownership and responsibility in most people.

This is one of the easiest tactics to implement. The next time you hear a question that all could be added to, immediately point it out to the speaker. In my experience, most people are very receptive to the idea.


What is the context for this post?
I believe some software bugs are born outside of code. I believe testers should try, where possible, to prevent potential bugs before a single line of code is written. Testers can play a big role by continuously asking context, polling for expectations and explicitly communicating assumptions and potential risks about the software. This post is one in a series of tools, questions and tactics that testers can use to set better context.

Arunkumar Muralidharan
I want to find out what conditions produce remarkable software. A few years ago, I chose to work as the first professional tester at a startup. I successfully won credibility for testers and established a world class team. I have lead the testing for early versions of multiple products. Today, I run Qxf2 Services. Qxf2 provides software testing services for startups. If you are interested in what Qxf2 offers or simply want to talk about testing, you can contact me at: mak@qxf2.com. I like testing, math, chess and dogs.

© 2013-2017, Arunkumar Muralidharan. All rights reserved.

One Comment

Leave a Reply to Testing Bits – 1/12/14 – 1/18/14 | Testing Curator Blog Cancel reply

Your email address will not be published.