Bug Reporting Best Practices

Bug Reporting Best Practices
Here is the excellent post written by Marie Hagman. This is one of the post where you can find comprehensive details about “how to file a good bug report”.

Which Bugs Get fixed?
To make the most impact on the product you want to spend the most time on the issues that are most likely to be fixed.

Bugs that get fixed:
Affect many customers
Are embarrassing or do not convey professionalism. Ex: fit and finish bugs
Are easy to fix
Bugs that less likely to be fixed:
It would be great to fix every bug in the product, but it’s also great to ship J. In prioritizing which issues to fix, here are the some factors that cause certain bugs to miss the triage bar. Bugs that are least likely to be addressed:
Are not reproducible or very hard to reproduce. This may be because the problem occurs intermittently or there are not enough details in the bug report
Have strange and complex steps to introduce failure
Have no perceived customer impact
Are edge cases
Risk introducing greater instability through the bug fix then the bug itself causes. Especially late in the product cycle, the bar for these types of bugs is very high because the bugs that may be introduced by the fix we will likely not have time to fix.
Found a bug? Dig deeper…
To create the highest quality bug report which will save developers time and increase the likelihood the bug is fixed, a little extra work goes a long way:
Try to find a more general repro
Are all of the steps required?
Is the bug tied to a single setting or is there a small range of cases? Identify the range.
Is the bug more serious than it appears?
What other user actions cause the error to occur?
Does the error occur with different settings or options selected?
Look for follow-up or related errors
How to file a good bug
Here are some tips on how to create a great bug report that will enable your customer to action on it quickly. Often bug reports submitted lack key peices of information so triage teams send bugs back to customers to request more information. We don’t want to mistakenly resolve and issue as By Design, Won’t Fixed or Postponed, so providing a complete bug report helps ensure the best response from triages. We want to spend as much time as possible fixing customer bugs – to that end, high quality bug reports help us spend less time deciphering the issue and more time resolving it.

To file a great bug report:
Use clear and minimal repro steps
Include only one issue per report. If you have multiple issues together, file separate bugs, even if they are related. This allows us to deal with them separate. Even if you encountered them in the same action, they need to be treated seperately internally.
If possible, try variations to see if you can better nail down the issue. Do any of the Tools Options settings affect what happens with the bug? Example: internal vs. external help.
Example: In the Help system, help can be internal or external. Does it repro with both?
Avoid jargon or terms that may be difficult to understand.
Make sure other customers will easily understand the bug
Bug Titles
Bug titles should completely and succinctly describe the issue. Internally, we spend a lot of time querying the bug database and looking at lists of bug titles. It saves time when we don’t need to open the whole bug report to know what the problem is.
Here are some tips on writing bug titles:
Fully capture the essence of the bug. We see a lot of partial titles that require more information. Example: “Autosave function” is not a good enough title. What about autosave? When the bug comes in, we put it in a bucket. The title should provide enough information to differentiate it from other bugs in the same bucket.
Think about it from the perspective of other customers trying to find your bug.
You can start by considering the keywords that you used to search for dupes before filing your bug.
Include the specific name of the components involved in your bug in the title. Toolwindow, dialog, designerExamples of Bug Titles
Most of the improved titles are longer, but not overly long. Don’t include unnecessary commentary either.

Original Title
Improved Title

“Search selected text”
“Find and Replace dialog should default to last-searched term”

“Control Tab Files”
“Had to press Ctrl-Tab twice for toolwindow selection dialog to raise”

“Change filename in Solution Explorer”
“Changing case of a filename in Solution Explorer doesn’t take effect”
Repro Steps
Steps to reproduct the bug are the most import part of a bug. Investing a little extra time in this area helps developers immensely. When creating repro steps:
Always try to recreate the bug before writing the report
Walk through the steps of your bug and make sure you didn’t leave out a step.
Could someone reproduce the issue without familiarity with the feature?
Start your repro steps from empty IDE. Don’t assume that a project is open, or a dialog is open. Don’t assume that the title has already been read when you write the repro steps. Often times, if a bug occurs on a dialog or an options pane, the reader of the bug won’t know how to get there.
Repro Steps Example
1. Choose Help->Search
2. Search for "integer"
3. Right click on a result and uncheck "Show Abstract"
4. Scroll down to the bottom of the list
Result: White space appears, because the scroll region didn't recalculate after hiding abstracts
Expected: After hiding abstracts, scroll region adjusts to match the search result display region
Descriptions
Descriptions should provide all the other useful information about and issue that is not captured in the repro steps some of which may include:
Does the bug repro on other hardware or software configurations
Are there configuration dependencies? Install options, Tools Options settings, etc.
Is the bug new in this version?
Attachments
Attachments are extremely helpful, especially for fit and finish UI bugs.
A picture is worth 1000 words. Screenshots with comments are priceless.
A picture doesn’t replace repro steps. The bug should still be captured in text even if a screenshot is attached.

Exploratory testing

Exploratory testing
Check out this video to understand what is exploratory testing.

Getting Respect for Testers: Seven Tips :By Micahel Bolton

Getting respect and gaining the devlopers confidence in you and your bugs is one of most important ingredient for being a successful tester. Read this inresting article below by Michael Bollton

A recent discussion in the Agile Testing discussion group prompted some of these observations about how a tester can gain respect from developers.

The first observation is that, in the long run, although sponsorship is important, no person will make the case for you and your work more compellingly than you and your work will make it. A good manager will pave the way for you to gain credibility, but ultimately it is up to you. Things willhappen if you make them happen, but if you sit idly and wait for respect, you'll still be waiting years from now.I have found that interesting, committed people generally like to talk about themselves and what theydo. Developers almost always appreciate testers who are genuinely interested in understanding the developers' work. The way to express your interest is to ask questions and to show a desire to learn what they're doing and how they're doing it. Start by engaging with a developer that is interesting and committed quality work, and is willing to talk with you. If there's a choice, choose the approachable ones first, but don't ignore the "unapproachable" ones. People with an "unapproachable" reputation may simply have been approached by the wrong people in the wrong way. Make yourself the right person, and approach them in the right way for them. That is: respect their terms. Learn about the Meyers-Briggs Type Inventory (MBTI) to help recognize, understand, and deal with the fact that people have different temperaments.

Second, reward their trust in you by making good use of the things they tell you. Use those things tohelp sharpen your own saw. Learn about the domain in which you're working, learn about theprogramming language. Use the knowledge to devise powerful tests that will help to find problems before they’re released. Try to encapsulate that knowledge for other testers, the support department, or the company’s knowledge base.

Third, apropos of the last point, do your work in public. At one organization, I found myself consistently answering questions in company forums from less experienced techs and testers. My profile rose when I provided correct answers. Perhaps more surprisingly, my reputation didn't fall when the developers had to correct or clarify me, as long as I acknowledged the error and thanked them for the clarification. No matter what happened, the techs had their answer, I usually saved the developers some time, or I acted as a useful foil to them. I learned a lot in the process.

Fourth, don't waste their time. If they suggest that you read something for more information, do your best to read it; then ask them more questions about it, partly to clarify your understanding but also to signal your interest, your diligence, and your curiosity. Save time for developers by making bug reports and other communication as clear as you're able. Don't assume that you're doing a good job; an absence of feedback might mean that the developers need nothing more from you, but it might also mean that they're ignoring everything you send them. Solicit feedback to make sure that they're finding your reports effective: "Did you get everything you needed from that report? Is there another tack that I could be taking to make reports work better for you?"

Fifth, ask them how you can otherwise best help them to do their work. Consider ways to help them within the context of services that testers are supposed to offer in your organization. As an example, help the developer set up and maintain smoke testing systems. Ask to be invited to code reviews or inspections as a scribe. Be prepared to extend your department’s services if you see a reasonable and justifiable need. If the boss hasn't given you permission, remember Grace Hopper's Law: it is easier to beg forgiveness than to receive permission.

Sixth, check your ego at the door. If you are excessively arrogant, no one will like you. On the other hand, if you behave timorously, as though you were a second-class citizen, people will find it easy to view you as one. Nobody emerged from the womb knowing his chosen trade; everyone learned this stuff from someone else. Seek explanations and understanding, and if you get attitude about that, don't
take it personally. Behave like a peer and a colleague, and you’ll more likely be treated as one.

Seventh, let your work speak for you. Excellent reports, compelling questions, and interesting tests will tend to attract positive attention. The best was to garner respect and support though? Just Find Cool Bugs. As I evolved in my career as a tester, I was consistently able, by skill and sometimes by luck, to find some really horrible problems. I’ve sometimes seen testers who seem reluctant to communicate bad bugs. Developers generally liked the nasty ones, because developers are fundamentally problem-solvers, and interesting bugs give them interesting problems to solve. The more interesting the problem we present, the greater our credibility.

Therefore: Just Find Cool Bugs!!