This tip is based on my own experiences of late. I’m very curious how other testers/developers feel about this tip.
State the PROBLEM Clearly in a Single Sentence
It’s easy to confuse stating the CONDITION with stating the PROBLEM. Here are two simple examples, one states the condition, the other states the problem:
The Scout rank does not have a Board of Review requirement.
The Scout badge should not have a Board of Review requirement.
The first is what a user sent me. The second is what I entered in PivotalTracker. Why? Because the first one doesn’t actually describe the problem. It simply describes the condition that, in scouting, the Scout badge is earned without holding a board of review. Depending on how you read that, you might have come to the conclusion that, in TroopTrack, the Scout badge is supposed to have that requirement but does not. In fact, the opposite was true – the user was describing the requirement, not the problem.
Bug reports that do this really well are, in my experience, easier to reproduce and fix, but it requires the tester to make a value judgment about the way things should be. I suspect some testers are philosophically opposed to this.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!
3 responses so far ↓
1 Dennis Gorelik // Feb 24, 2010 at 4:22 am
I agree that usually your second version (describing a problem) is better.
However it's not always possible to state a problem in one statement.
Sometimes it should be split into several sentences.
For example:
===
Step by step:
1) Open home page.
2) Enter Scout's name "Scout1" and click search.
3) In details section the Scout rank does not have a Board of Review requirement.
4) The Scout rank in details section should have a Board of Review requirement.
===
So problem description could be longer.
On the other hand, if you need short title, you may consider simplify it to: "Scout rank without Board of Review".
It doesn't clearly explain the problem, but gives convenient short label to refer to the problem in discussions.
Bottom line: it depends.
2 Joshua Lewis // Feb 24, 2010 at 5:55 am
I think maybe some BDD ideas can help here, in terms of stating pre-conditions, performing an action, then describing expected and actual post-conditions (also similar to AAA syntax for unit tests).
3 Dave Jones // Feb 26, 2010 at 1:27 am
I think David is saying that the one-line bug summary needs to state the problem succinctly and accurately. Dennis, the steps to reproduce the problem should be in the bug report details. So I think your recommendations together really address the problem.
If the full bug report describes the problem, the symptom, steps to reproduce, etc, then I'll just modify the one-line summary if necessary so I know what it means when I see it in reports.
However, if there isn't adequate information to reproduce the bug, or for a developer to even know what problem is being reported, I tell the team members to immediately mark it as "needs more information" or "cannot reproduce". Too often I see developers waste their time trying to figure out the problem just because the tester can't write a bug report.
Leave a Comment