Wednesday, June 16, 2010

Humor and bug submission - comedy or tragedy?

One of the testers working on the validation project I am leading, submitted a bug with the following title: "Unbelievably short period of appearance of the feature menu - feature impossible to use". In addition he mentions in the bug description that the feature is impossible to enter for anyone but an experienced "Quake Tournament Player".

Both the title and the description made me laugh, especially since I remember that many years ago, a few of my fellow testers and myself used to spend our lunch breaks playing Quake.

While enjoying the humor, all of my bells of bug submission guidelines rang. We know that bug submission is a very sensitive and responsible task, and the bug must be presented in an objective manner, which was not the case here. On the other hand, reading the bug gave me a real laugh, which we need while working so hard. In addition, I can even say that using the funny example helped me identify with the end-user described as not an experienced "Quake Tournament Player", since I suck at playing arcade Quake, too.

We know that humor should be used wisely - to relieve tension and give us a good laugh that relieves the stress. Even the serious discipline of medical treatment is aware of the contribution of humor and laugher to the patients and invented the profession of medical clown.


Should we go in the sterile “BKM” direction or share our sense of humor even in our bug descriptions?

Since I value risk taking, I would say that sometimes we can allow ourselves to go a bit wild with a few guidelines:
  • Make sure you personally know the possible stakeholders who will look at, or work on, the bug, and make sure they know you and value a sense of humor.
  • Don’t start with jokes before you've established your credibility as a serious bug submitter.
  • Don’t do it too often. Once or twice in a project life cycle is enough.
  • Make sure your joke is funny (perhaps you would like to test it before hand).
  • No need to mention that the joke should not be offensive in any manner to anyone.
  • At the end, make sure that the bug is perfect and clear from all other aspects. A bug with a joke, but without steps to reproduce, might look even worse than just a bad bug missing steps to reproduce.
  • Understand that following all of the guidelines above cannot guarantee that you will not fall into hidden traps.

Comedy can easily turn into tragedy. Sometimes taking risks pays off, and sometimes not. Do it, but at your own risk!

3 comments:

  1. I am not alone. I had been thinking on this topic for a long while and you blogged about it. Wonderful.

    Humor is a skill. Not everyone would be able to do this and for those who possess that skill, they could play it to their strength.

    Of course, you didn't say, "Use it every time" but instead you had points of in what context it might work.

    In the context where you have a good relationship with the developer and your are mentioning a bug in passing, it is absolutely OK to add humor into it. Some of us already do that during verbal bug reporting.

    I would love to meet you and Shmuel. You guys rock.

    ReplyDelete
  2. In this case the humor did not detract from the bug report and may have added a bit to the problem description, namely that the menu did not remain visible long enough to be useful. I would suggest, though, that this example pushes the limit to which humor should be part of a bug report.

    ReplyDelete
  3. Pradeep,
    Thanks for your comment, and especially for adding the word "Skill" which was missing from my post.
    As a good student i'll try to summerize in essence: Skill gives you the ability to identify the context so you could select the appropriate method

    Or in a formula (pardon for over simplifying):

    Skill + Context > BKM

    ReplyDelete

Note: In order to avoid SPAM, comments are moderated before they are published.