Thursday, March 13, 2008

Writing a Problem Report

Many testers are not concentrating the details, while entering a defect. I have seen few guys entering just one line as bug description. Also they are not ready to put the details of the environment. For few scenarios, they can improve it by attaching proper snapshots. As a tester, we should give the right steps to reproduce the issue. Managers should not encourage informal ways like oral communication, email notes, etc.

Cem Kaner has written few articles about Bug Advocacy.
Bug Advocacy: PDF
Bug Advocacy: Video

Also I would like to give two quotes from his famous book.
Book: Testing Computer Software By Cem Kaner, Jack Falk, Hung Quoc Nguyen
ISBN: 0471358460


If your reports are not clear and understandable, bugs won't get fixed. You should spend minimum time needed to describe a problem in a way that maximizes the probability that it will be fixed. The content and tone of your reports affect that probability. The point of writing problem reports is to get bugs fixed.

Nobody likes being told that what did wrong, wrong, wrong. As a tester, that's what you tell people everyday. You can ensure your unpopular by describing problems in a way that tells the programmer you think (s)he is sloppy, stupid or unprofessional.

No comments: