Software Development Cross Solution - Index of - Free

Anatomy of a bug report
Different bug tracking systems give you different templates for submitting a bug, but
the basic elements are the same. As a general rule of thumb, the more information you
can provide in a bug report, the better. Even if you work on a bug and don’t fix it, you
should record what you’ve done, and any ideas about what else might need to be done.
You—or another developer—might save hours by referring to that information when
you come back to that bug later.
A good bug report should have:
Summary: Describe your bug in a sentence or so. This should be a detailed action
phrase like “Clicking on received message throws ArrayOutOfBoundsException,”
not something like “Exception thrown.” You should be able to read the summary
and have a clear understanding of what the problem is.
Steps to reproduce: Describe how you got this bug to happen. You might not
always know the exact steps to reproduce it, but list everything you think might have
contributed. If you can reproduce the bug, then explain the steps in detail:
1. Type “test message” into message box.
2. Click “sendIt.”
3. Click on the received message in the second application.
What you expected to happen and what really did happen: Explain
what you thought was going to happen, and then what actually did happen. This is
particularly helpful in finding story or requirement problems where a user expected
something that the developers didn’t know about.
Version, platform, and location information: What version of the software
were you using? If your application is web-based, what URL were you hitting? If
the app’s installed on your machine, what kind of installation was it? A test build? A
build you compiled yourself from the source code?
Severity and priority: How bad is the impact of this bug? Does it crash the
system? Is there data corruption? Or is it just annoying? How important is it that the
bug gets fixed? Severity and priority are often two different things. It’s possible that
something is severe (kills a user’s session or crashes the application) but happens in
such a contrived situation (like the user has to have a particular antivirus program
installed, be running as a non-Administrator user, and have their network die while
downloading a file) that it’s a low-priority fix.
ending an iteration
What else would you want to see in a bug report? What kind of information would
you want to see from the user? How about any kind of output from the system?
Download at WoweBook.Com
you are here 4 337