Wednesday, February 2, 2011

Advisor, Not Interrogator

Testers are questioners, for the most part. They ask questions of a system: "what happens when I do this?" They ask questions of product management: "what should it do when...?" They ask questions of developers: "I'm seeing this funny thing; any ideas on what I might do to track it down?"

For the most part, this is a good thing. The testing role is ultimately about communication between the system and the humans involved in in the creation and use of that system, and about communication among the humans about the system.


Questioning plus aggressiveness equals antagonism.

And that's not helpful to anyone.

Asking questions is about achieving clarity. If that's not your purpose, then you're over the line and all you're doing is interrogating someone. For example, if I'm asking questions to:
  • show someone they haven't thought through a problem
  • demonstrate in front of our boss that my co-worker is making unsubstantiated claims
  • prove that only a moron would ship the software with such large risks
  • paint a doom and gloom picture of the current state of affairs relative to our intended release date
  • make sure someone knows that dev is making dumb mistakes.... again
then I'm not helping. All I'm doing is making my relationship with the rest of the team antagonistic. I'm priming them to be defensive the next time I open my mouth. In short, I'm being a truly terrible team member.

So don't.
Just stop.

You don't have to be the smartest guy in the room. You don't have to be the best informed. You don't even have to be the one to tease out all the problems. No, instead you have to be a good team member.

Now, asking questions is perfectly fine. It's a large part of how we get our jobs done. Frequently a question will trigger identification of a new risk, or an understanding that maybe your co-worker is leaping to conclusions rather than pulling his weight and doing the work to get to those conclusions. But don't force it. Forcing it makes you the bad guy, and a tester is most effective when he is a trusted advisor.

So, how do we ask questions nicely? There's no universal answer, but consider these:
  • Be polite. Start with thanking the person for their time and for providing information. If your questions are in response to something (a requirements doc, for example), then start by acknowledging the work they put into this.
  • Lay off. Don't respond to every email with a barrage of questions.
  • "Me" not "you" phrasing. Using the word "you" in a question increases your chances of being seen as antagonistic, especially if you're also using a negative word. Avoid "Didn't you think that ___" in favor of "What about ____". Same question, but less attacking.
  • Shrink the audience. If you are at all worried that this might come across as negative, send it to as few people as possible. Talk to the developer privately rather than standing in the meeting and asking. Drop a bunch of people off a cc list and just email the developer privately.
  • Make yourself a partner. Put yourself out there with statements with the questions. "Looking at your performance graph, I see a dip at 10000. I wonder if that's the cache filling up. What do you think?" is better than "Why the dip at 10000?". It doesn't matter if you're right or wrong; what matters is that you've shown you thought about this and that you're willing to do some work, too.
So before you go asking a lot of questions, pause and see if you really want to know the answer, or if you have an ulterior motive. You can only be effective if you're the good guy. So be the good guy.


  1. Hi, you said that "Asking questions is about achieving clarity" but also that "if I'm asking questions to show someone they haven't thought through a problem...then I'm not helping."

    So I'm wondering how to help other people achieve clarity without asking them questions? Particularly in those cases where it looks like they haven't thought something through but you don't want to presumptuously assume that without first checking (i.e. by asking questions) if there were any reasons that justify their behaviour that you aren't aware of.

  2. Anonymous, it's not the easiest situation.

    You went wrong when you decided that you needed to "help other people achieve clarity." The instant you make that decision you have made several assumptions:
    - that you understand the situation
    - that you understand what the other person is trying to achieve
    - that the other person is wrong in his/her thinking
    - that the other person is seeking clarity

    Any one or more of those assumptions may be flat out wrong. And yet you've already decided that every single one is true when you set out to help someone else achieve clarity. What the other person will hear is not, "I'd like to help you understand better". Instead, what the other person will hear is, "You moron. You obviously don't get it. Okay, fine, I'll walk through it with you yet again. Maybe if I speak in little words you'll finally understand."

    That only time you may assume that the other person is seeking to have enlightenment rammed down their throat is when you are explicitly taking the role of "teacher" with the direct request and acknowledgement of the other party.

    Reread your comment and note some phrases:
    - "Justify their behavior." Unless they work for you, are your child, or have asked you, no one has to justify anything to you.
    - "help them achieve clarity". See above. You don't know that your clarity is correct or complete, and you sure don't know that you understand everything they don't know.

    So, don't drop the questions. Drop the "I know more than you" attitude.

    A better goal would be to elicit and provide information. Stop. That's it. With more information out there, you can both make better-informed decisions.