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.

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.