Confirm
486
edits
Changes
m
→How to Clean Incoming Bugs
as possible. These techniques really apply to bugs QAs are filing as well.
# <u>Understand the bug:</u> Read very carefully to try and understand what they're talking about.
# <u>Look for duplicates:</u> A lot of bug reporters mistakenly assume their bug wonhaven't have been filed yet. Search for eventuel previously filed bugs by searching for keywords in the summary in the bug, and try alternate spellings and synonyms. For example, if the bug is about the control key, try spelling it ctrl as well. Look through fixed and duplicate bugs when you search for duplicates.
# <u>Ask for missing information or clarification</u>: You can't test every bug yourself, especially those with incomplete information. Try not to waste your own time. Keep asking the reporter for more information until you have enough to try it yourself. If they did not provide build information get that right away, because many bug reports are for older versions that have long been fixed.
# <u>Reproduce the bug</u>: Change the status from Unconfirmed to Confirmed 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. Often times, reading so read the bug description over very carefully . It will reveal clues, and bring up questions. If you are convinced the bug was filed in error, and requests for clarification don't net results, then mark the bug WONTFIX or INVALID. When marking WONTFIX or INVALID, be sensitive to the fact the 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."# <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 [http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows "How to Really, Really Help Developers on Bugs" ] 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.
# <u>Ensure a concise and precise summary</u>: It is reasonable to edit the summary a bit if it will help people understand the bug more quickly or will clear up something that's misspelled or incorrect. Check to see that the summary is clear, concise and describes the problem as fully and correctly as is reasonable in a short space. Make sure it contains the words people would probably search for before filing a duplicate bug. To risk stating the obvious, the spelling in the summary matters because searches will for "Escape" will fail if the reporter wrote "Escpae".
