What's programmer's first reaction if SQA shoots a bug/issue with short description?

Question

What's your first reaction when SQA shoots a bug/issue to you with short description?

Do you have any rules for SQA's report at your company? Got any test case document or testing procedure ?

Answer 1

Normally, I would post a following comment to the issue/bug: "Can you please elaborate?". It resolves the problem in most of the cases.

Btw, you don't need procedures to ask one of your colleges to provide more info.. I think.

Answer 2

Yes, we require:

1. What they were doing
2. Where it occurred
3. What browser
4. Provide the error description
5. Provide a screen shot if possible.
6. Try an recreate if possible.

Answer 3

I'm a test manager and I can tell you that this is my pet peeve. There are 2 facts about testing: "Testing is a service industry" and "A tester's sole output should be a bug report". If you aren't receiving sufficient data you have my full permission to apply a degree of percussive education.

Dependent on your company, I would suggest any or all of the following:

1. Reject the bug, "Closed No Action", wait for the fallout
2. Contact the test team lead and hand them the recently-applied clue-by-four and suggest they re-apply.
3. Ask for more information in a polite fashion letting the tester know that the standard of work is below par (gently)

I've yet to meet a developer who has complained of too much information in a bug. They are always able to sort the wheat from the chaff, even if the tester isn't able. It then falls to the tester to supply any information requested by the developer. It also falls to the tester to jsutify why they think it's wrong and resist calls to close it if they believe it is negative behaviour.

A good bug report should follow this cycle:

1. Tester: "Hey, do you have a second? X does y when I apply z, that seems wrong to me. I've checked the requirements and I'm fairly sure it should do w" Developer: "Really? It works on my machine Well, raise it in the tracker and I'll have a look"
2. Bug gets raised in bug tracker.

Bugs should tend to the verbose. They should include: * Versions of s/w, * platform, * configuration, * requirement under test, * steps to reproduce, * expected outcome, * observed behaviour, * log files, * notes, * possible causes * etc. etc. etc.

Software then gets released, bug free, and peace and sunshine fill the land.

There is excellent information on the Bugzilla project page (here)

You can also get great information on www.satisfice.com (James Bach's RST course notes) and on the ISTQB/ISEB pages