Imagine you’ve just joined a project that’s been going for 6 months. Maybe you’re the first tester to enter the project for months, maybe the old tester quit or died or something. Maybe you’re just doing regression testing. Anyhow, you’re left with a heap of issues that look something like:
Error occurs
Editing field does not work
Save not working
So you open the first one as it needs retesting, hoping for more clues and you get this:
Issue: Error happens when I create a new banana and click the “Next” button.
——-
Fixed.
Nice. Unfortunately you don’t know how to create a new banana and you don’t know which “Next” button is being talked about. So you’re going to have to hassle someone or several someones to figure out what to do. Now consider that you have about 55 issues to get through. Feeling pretty crappy now, aren’t you?
For god’s sake, do yourself and everyone a favour when you raise issues, and raise them something like this:
Title: Should state what area, what page and what the problem is.
Repro steps: These are ALWAYS necessary. The best approach is to write them so that someone who has never used the software. At the very least you should start from the beginning, use point form and include all the major steps, no matter how simple and obvious they might seem to you.
Expected: What you expected to see at the end of the repro steps.
Actual: What you really saw at the end of the repro steps.
Version number: The version or build number you found the bug in.
If you cannot repro the bug, then there isn’t much point in raising it since it will be near impossible to fix. That’s why you should try like hell to reproduce every bug you find, there’s no point in letting a good bug go to waste.
It’s really easy to get lazy about this and use the logic of “the developer already knows what I’m talking about so I don’t have to give details”, but you and the dev are not the only ones looking at the issue. Take pity on the poor person who has to look back at your issue for any multitude of reasons.