Monday, September 21, 2009

Actionable Issues

I was talking with someone at work today, and he was telling me about an issue he's having. He had a problem on one system (bad switch), and he logged a bug and it was dealt with (new switch!). He now has another system with the same type of (bad) switch in it, and it isn't a problem, but he's worried it might become an issue. As a preventive measure, he's gathering logs and starting to collect data; if it fails, he'll have some good prefailure data.

(By the way, I applaud this effort. It shows some real thinking ahead. But that's not the point of the story.)

Anyway, he came to me asking if he should log a bug for this.

And I said no. He is missing one key criteria:

Bugs should be actionable.

Let's say I'm on the receiving end of this bug. There are only a few things I'm going to ask myself:
  1. What's happening?
  2. How is that different from what we would like to have happen?
  3. What do I do?
If you can't answer those three questions, you don't have a bug (or issue or ticket or whatever you want to call it). You might have something that will one day become a bug, but you don't have a bug.

So whenever you're logging an issue, make sure you've elucidated the things the recipient will need to fix the problem. Give the recipient desire and action. One without the other will not help your problem get solved.

Posted by at 9:14 AM

4 comments:

  1. I never thought a tester's job is to determine the fix. So, perhaps I'm not sure what you mean by actionable.

    *Anything* is actionable, strictly speaking. Knowing some piece of information might affect your behavior in any number of ways.

    Seems to me what you need for a bug report is to have in your possession a bit of information that your client may need: information about an attribute of the product that threatens its value. They may not be able to fix it. That's not your call.

    In the case you described I would definitely report the matter. I might report it as a formal bug, or I might "MIP" the bug (mention in passing). Either way, I would offer the information to my client.
    ReplyDelete
  2. We went with what you're calling "MIP" for the simple reason that there's nothing to fix. An engineer or product manager or my boss ( :-) ) is going to look at it and say, "okay. what do you want to happen out of this?"

    I tend to operate on quite a tactical level - it works for me and I don't worry too much about the theoretical extension to *everything*.
    ReplyDelete
  3. Tactics serve the mission. What is our mission?

    Do you really think I should avoid reporting a bug because I, the tester, don't know what to do? Maybe someone ELSE will know what to do. Maybe no one knows what to do, and so we'll live with it, and the tech support people will be better able to explain the problem.

    My mission is to provide information that my clients need. That's not some theoretical notion.
    ReplyDelete
  4. Ahhh, I think I see the disconnect now, James. "File a bug" is one way we provide information. There are of course others. This case, for example, wound up in the wiki, which is where we keep the vast majority of information - documentation, trend reports, etc. That way it's easily referenceable if it turns into a problem we have to do something about, and if not it's simply there to tell us about "standard state" (also useful, but in a different way).

    Providing information matters. There we completely agree.
    ReplyDelete

Subscribe to: Post Comments (Atom)