Anybody who has written code for public use will probably have received at least one bad bug report. Reports that say nothing ("It doesn't work!"), reports that make no sense, reports that don't give enough information,reports that give wrong information. well ... as a coder i felt it's a horrible job to work on UI bugs and one reason is bad bug reports. However, not all bug reports are unpleasant and sometimes we received a wonderfully clear, helpful, informative bug reports.
Quality of Bugs:- depends on following points.
1. The development process (how much time between releases)
2. The product planning (how much change per release)
3. The QA Cycle approach
4. % of bugs would have been found within unit test cases or web services testing?
5. % of bugs platform(dependencies like software, os, browsers etc ) specific? how many are UI bugs ?
6. % of bugs as known issues.
Points that should keep in mind:-
1. Be specific. If you can do the same thing two different ways, state which one you used. "I refreshed page" might mean "I clicked refresh button" or "I pressed F5". Say which you did. Sometimes it matters.
2. Be verbose. Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. Be careful of pronouns. Don't use words like "it", or references like "the window", when it's unclear what they mean.
3.Read what you wrote. Read the report back to yourself, and see if you think it's clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.
4. You report a bug because you want the bug fixed. it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help us by supplying all the information needed.
5. "It doesn't work."case Give the programmer some credit for basic intelligence, :D if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information, providing this information is the purpose of a bug report. More information is almost always better than less.
6. "Works for me. So what goes wrong?" case Possibly the fault doesn't show up on every computer, your system and theirs may differ in some way. Possibly you have misunderstood what the program is supposed to do, and you are both looking at exactly the same display but you think it's wrong and they know it's right. So also describe what happened. Tell us exactly what you saw. Tell us why you think what you saw is wrong.
7. What happens if bug gets rejected? Rejected bugs fall into two categories:-
7.1. It was rejected because it was not a bug.
7.2. It was rejected because development team do not feel like working on it. :D
