Jump to: navigation, search


114 bytes added, 13:45, 27 September 2007
no edit summary
#* If it's a crash, ask for [ Talkback data]. ([[Mozilla_QA_Community:Talkback|more info on Talkback]])
#* If the reporter still can reproduce but you can't, ask him nicely if he can test a nightly build of [ Firefox] or [ SeaMonkey].
# <u>Reproduce the bug</u>: Change the status from Unconfirmed to New if appropriate. For instance, for many Core bugs, like layout or DOM bugs, it is often needed to have a minimal testcase before a bug can be confirmed. Many times, bug reports are confusing and difficult to reproduce, so read the bug description over very carefully. It will reveal clues, and bring up questions. If you are convinced the described problem is in fact the desired behavior then mark the bug INVALID. If the bug was filed in errorreport does not have enough information to be of any value, and requests for clarification don't net results, then mark resolve the bug INVALIDas INCOMPLETE. When marking INVALID, be sensitive to the fact that the bug reporter may get offended. While changing the status it's often good to write something like "This appears to work as designed, please reopen and provide more information if you believe this is in error."<br>If you're convinced you understand the bug, and you can't reproduce the bug, you could resolve the bug to WORKSFORME. But be careful with this, the bug can be a duplicate of a bug that has been fixed, so try to search for that bug. Also, you need to test on the same platform as the reporter, because it could be a platform dependant bug. It is best, if the original reporter marks a bug WORKSFORME, after he tried with the latest nightly build, tried with a clean profile, etc.
# <u>Simplify the bug testcase</u>. You're the lead investigator -- so try to get enough information to turn intermittent or hard to reproduce bugs into something that is easy to reproduce. See more on this in [ "How to Really, Really Help Developers on Bugs -- Minimal Testcases"] below.
# <u>Ensure appropriate hardware/platform tests</u>: most bug filers will only have tested on one platform. If bug was filed for a particular platform, see if it's a bug on another platform. If it's been reproduced on at least 2 platforms that aren't both Unix/Linux, then go ahead and mark it All/All ((Hardware/OS). Most bugs are actually All/All. It's useful to get a feeling of when to do extra tests and when not to waste your time, but this comes with experience. For example, OS X uses many native Carbon form controls and menus whereas Windows and Linux do not, so form control bugs on Mac are probably just Mac-only. However, a bug in how HTML links are dealt with is almost certainly a bug on all platforms. Also, it's useful to know the QA community so that you can ask for help when you don't have the right hardware/OS to test a particular bug with.

Navigation menu