Thursday, July 23, 2009

Who Do You Tell When?

You've found something. Something that's a bit scary. Maybe you're late in a release, maybe it's something that on the surface looks like it ought to affect a whole lot of your customers, maybe it's a potentially huge flaw in that feature that marketing's out there touting right now. This isn't your run of the mill bug.

You've got to get the word out, and the sooner the better. So let's go running through the halls! Or... wait.. maybe not.

Let's step back for a second and look at the groups of people you a tester interact with:

Mostly, you work within QA - working with, talking with other testers. A bit less often, but still a lot, you work with the developers on your project. Still less often, but regularly, you'll be in touch with the project team as a whole; think documentation, project managers, support, etc. And least often you interact at the whole company level - executive management, other project teams, etc.

Information flow works the same way. The closer to your inner circle, the more you share knowledge about the meaning and implication of what you do. The farther out, the less context you share.

Take, for example, the bug you just found (say, the product core dumps when more than 20 users try to change their passwords simultaneously):
  • Your fellow QA types will understand how long a change password operation takes (and therefore how likely collision is), will know that this is an area of code that is usually pretty shaky and that fixing the bug is fairly likely to introduce something else. They can also help figure out how reliably this happens.
  • The developers you work with will understand that this is an area of code they've been desperate to refactor and that touching this is a bit scary. They won't have all the details, but they'll know enough to walk around it when possible. They'll also want to know how often it happens.
  • The project team will know that this is a fairly rare operation and that marketing is planning to announce the release on the ship date at a huge conference, so slipping would be Very Bad. They'll also know that dev is a bit gun shy about fixing this one at this point in the release.
  • The company will know... well, probably nothing. This one would most likely stop at the project team.
In general, your inner circle is best equipped to handle a lot of details and a lot of uncertainty. The further out you go, the fewer details and the less uncertainty are plausible. The project team, and especially the company aren't in a position to truly evaluate the implications of "we don't know yet". The closer someone are to you, the more uncertainty your conversation can have and still have meaning. As you tell people who are less and less involved with all the details of what you're working on, the more you have to know and the more you have to explain.

So who do you tell about a bug and when?
  • Tell your inner circle as soon as you found it. Let them help you track it down more.
  • Tell your next circle as soon as you have a handle on it and know what the unknowns are. You don't have to have all the answers yet.
  • Tell the project team as soon as you can summarize it eloquently, including effects and frequency of occurrence.
  • Tell the company only when you know what is going on, what the effects on the project as a whole are, and what you're going to do about it.

Long story short, tell people about an issue when you have codified it enough that it will have meaning to them.

1 comment:

  1. Hi Catherine,
    Its quite true that we have different layers above us, so while communicating any issue, we have to prepare according to level where we want to pursue our issue, because developers will consider our point in terms of development effort he needs to put in while higher management will think that how much important this issue is for the client and etc.
    I think as a QA resource, you should have your basket full of arguments for each layer.