QA/Triage - Revision history

Radiant chains: /* How to Clean Incoming Bugs */ copyedit

2010-02-16T06:13:13Z

How to Clean Incoming Bugs: copyedit

Tuggyne: /* How to Track Relevant Incoming Bugs */ Going into more detail on how to track a given component by e.g. QA contact

2010-01-25T22:50:47Z

How to Track Relevant Incoming Bugs: Going into more detail on how to track a given component by e.g. QA contact

← Older revision		Revision as of 22:50, 25 January 2010
Line 28:		Line 28:
	Bugzilla preferences. Make sure to track the relevant component in		Bugzilla preferences. Make sure to track the relevant component in
	both [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&component=Disability+Access+APIs&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Core->Disability Access APIs] and in the products you care about, such as [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Firefox&component=Disability+Access&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Firefox (Firefox->Disability Access)] or Thunderbird.		both [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&component=Disability+Access+APIs&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Core->Disability Access APIs] and in the products you care about, such as [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Firefox&component=Disability+Access&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Firefox (Firefox->Disability Access)] or Thunderbird.
			One way to track a component is to find its default QA contact pseudo-address (e.g. folders-message-lists@thunderbird.bugs for [https://bugzilla.mozilla.org/describecomponents.cgi?product=Thunderbird#Folder%20and%20Message%20Lists Folders and Message Lists]) and [https://bugzilla.mozilla.org/userprefs.cgi?tab=email#new_watched_by_you add that address to your user watch list] (under Bugzilla's Preferences, Email Preferences tab).

	== How to Clean Incoming Bugs ==		== How to Clean Incoming Bugs ==

Gerv at 13:45, 22 August 2008

2008-08-22T13:45:09Z

← Older revision		Revision as of 13:45, 22 August 2008
Line 6:		Line 6:
	following these techniques you will help the important bugs get		following these techniques you will help the important bugs get
	fixed, as well as optimize precious developer time.		fixed, as well as optimize precious developer time.

			====Bugzilla Permissions====

			In order to perform some of the tasks in Bugzilla listed here, you'll need upgraded permissions for your Bugzilla account. This requires a small amount of proof of your competence - see the page about [http://www.gerv.net/hacking/before-you-mail-gerv.html mailing Gerv] for details of what's needed, and how to contact him for a permissions upgrade.

	== How to Track Relevant Incoming Bugs ==		== How to Track Relevant Incoming Bugs ==

Jesse: /* How to Really, Really Help Developers on Bugs -- Minimal Testcases */

2008-08-03T21:15:03Z

How to Really, Really Help Developers on Bugs -- Minimal Testcases

← Older revision		Revision as of 21:15, 3 August 2008
Line 93:		Line 93:

	You need to use your brain throughout this process. For example,		You need to use your brain throughout this process. For example,
	if the bug ~~is layout flow related~~, then the width of ~~your~~ window and font size may impact the results.		if the bug involves line wrapping, then the width of the window and the font size may impact the results. In this case, you can ensure that your reduced testcase will work for everyone by using "font-family: monospace;" and a width specified in "ch" units.

			For more detailed instructions, see [http://developer.mozilla.org/en/docs/Reducing_testcases "Reducing Testcases" on DevMo].

	== How to Help with Regressions -- Finding Regression Windows ==		== How to Help with Regressions -- Finding Regression Windows ==

Jesse: /* See Also */

2008-08-03T00:41:54Z

Mats.Palmgren: Updating to reflect latest ftp.mozilla.org reorg

2008-01-18T07:49:00Z

Updating to reflect latest ftp.mozilla.org reorg

← Older revision		Revision as of 07:49, 18 January 2008
Line 100:		Line 100:
	Here are some steps for finding a regressions window:		Here are some steps for finding a regressions window:
	# Take a guess when the bug might have broken -- any guess will do for a start, so just use your instincts.		# Take a guess when the bug might have broken -- any guess will do for a start, so just use your instincts.
	# Download and install a build from that date from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ ~~or from http://archive.mozilla.org/pub/ if you need to go back even further~~. I recommend installing the build in a directory named something like Firefox-03-11-06 so that you can go back to it during this test.		# Download and install a build from that date from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/. I recommend installing the build in a directory named something like Firefox-03-11-06 so that you can go back to it during this test.
	# Use a separate dedicated profile, without any extensions installed and start with -profilemanager.		# Use a separate dedicated profile, without any extensions installed and start with -profilemanager.
	# Test the build and write down the results. It's common to get confused since you are testing for the absence of a bug, so good notes are important. If the bug occurs, then you know you will have to search back further in time. Otherwise you will need to search forward in time. The optimal algorithm is to test the date exactly between the last known date when the bug didn't occur and the last known date when the bug did occur. Keep dividing by two and you'll find the day.		# Test the build and write down the results. It's common to get confused since you are testing for the absence of a bug, so good notes are important. If the bug occurs, then you know you will have to search back further in time. Otherwise you will need to search forward in time. The optimal algorithm is to test the date exactly between the last known date when the bug didn't occur and the last known date when the bug did occur. Keep dividing by two and you'll find the day.
	# In the end, make sure that the bug is marked with the keyword "regression", and add a very clear comment something like: "March 19, 2006 trunk: works, March 20, 2006 trunk: broken". When you have found a regression window within a day, then the actual hour the product was built becomes important. You can give this information with the [[MozillaQualityAssurance:Build_Ids\|build ID]]. Another option is to look at the time when the "firefox.exe" or "thunderbird.exe" was last modified. Then take a larger margin (by the hour) of that time. A third option, if you're paying attention when downloading builds in step 2 above, is to note the sets of numbers in the directory name; stripping the dashes from that string gives you the build ID in most cases (e.g., a build from <tt>/~~pub~~/firefox/nightly/2005-08-27-19-trunk/</tt> is a trunk build with a build ID of 2005082719).		# In the end, make sure that the bug is marked with the keyword "regression", and add a very clear comment something like: "March 19, 2006 trunk: works, March 20, 2006 trunk: broken". When you have found a regression window within a day, then the actual hour the product was built becomes important. You can give this information with the [[MozillaQualityAssurance:Build_Ids\|build ID]]. Another option is to look at the time when the "firefox.exe" or "thunderbird.exe" was last modified. Then take a larger margin (by the hour) of that time. A third option, if you're paying attention when downloading builds in step 2 above, is to note the sets of numbers in the directory name; stripping the dashes from that string gives you the build ID in most cases (e.g., a build from <tt>pub/mozilla.org/firefox/nightly/2005/08/2005-08-27-19-trunk/</tt> is a trunk build with a build ID of 2005082719).
	# An experienced QA can pinpoint the actual checkin with the problem, and CC the developer who was responsible to the bug. Finding out which checkin was responsible for the regression is possible with the [http://bonsai.mozilla.org/cvsqueryform.cgi Bonsai tool]. At the bottom of that page you can add dates ("between ... and ..."). When submitting the form, you get the list of checkins between those dates. When you know the build IDs of the last working and first broken builds, expand them back into dates and times to get a more precise set of results (e.g., a build ID of 2005082719 becomes 2005-08-27 19:00).		# An experienced QA can pinpoint the actual checkin with the problem, and CC the developer who was responsible to the bug. Finding out which checkin was responsible for the regression is possible with the [http://bonsai.mozilla.org/cvsqueryform.cgi Bonsai tool]. At the bottom of that page you can add dates ("between ... and ..."). When submitting the form, you get the list of checkins between those dates. When you know the build IDs of the last working and first broken builds, expand them back into dates and times to get a more precise set of results (e.g., a build ID of 2005082719 becomes 2005-08-27 19:00).
	# If you are very technical, it is possible to go even further. Some QAs who know how to apply patches and build their own Mozilla have even been known to find which part of a patch caused the bug, by building with or without each piece in a patch. However, this is really not necessary, so don't worry if you're not comfortable doing that.		# If you are very technical, it is possible to go even further. Some QAs who know how to apply patches and build their own Mozilla have even been known to find which part of a patch caused the bug, by building with or without each piece in a patch. However, this is really not necessary, so don't worry if you're not comfortable doing that.

Samuelsidler: MozillaQualityAssurance:Triage moved to QA/Triage: Great QA move of 2007.

2007-11-23T08:10:10Z

MozillaQualityAssurance:Triage moved to QA/Triage: Great QA move of 2007.

← Older revision	Revision as of 08:10, 23 November 2007
(No difference)

Mats.Palmgren at 13:45, 27 September 2007

2007-09-27T13:45:35Z

← Older revision		Revision as of 13:45, 27 September 2007
Line 44:		Line 44:
	#* If it's a crash, ask for [http://kb.mozillazine.org/Talkback Talkback data]. ([[Mozilla_QA_Community:Talkback\|more info on Talkback]])		#* If it's a crash, ask for [http://kb.mozillazine.org/Talkback 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 [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Firefox] or [http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ SeaMonkey].		#* If the reporter still can reproduce but you can't, ask him nicely if he can test a nightly build of [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Firefox] or [http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ 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 bug ~~was filed in error~~, and requests for clarification don't net results, then ~~mark~~ the bug ~~INVALID~~. 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>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 the described problem is in fact the desired behavior then mark the bug INVALID. If the bug report does not have enough information to be of any value, and requests for clarification don't net results, then resolve the bug as 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 [http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases "How to Really, Really Help Developers on Bugs -- Minimal Testcases"] below.		# <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_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases "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.		# <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.

Mw22: /* Intro */

2007-09-27T12:50:37Z

Intro

@@ Line 6: / Line 6: @@
 following these techniques you will help the important bugs get
 fixed, as well as optimize precious developer time.
 == How to Track Relevant Incoming Bugs ==

Mw22: /* How to Track Relevant Incoming Bugs */

2007-09-27T12:50:05Z

How to Track Relevant Incoming Bugs

← Older revision		Revision as of 12:50, 27 September 2007
Line 35:		Line 35:

	== How to Track Relevant Incoming Bugs ==		== How to Track Relevant Incoming Bugs ==
			In Mozilla, a QA must not only test and then file their own bugs, but must also help harness the incoming flood of community bugs for valid problems.

	The tool that Mozilla uses to keep track of bugs is [https://bugzilla.mozilla.org/ Bugzilla]. With Bugzilla's [https://bugzilla.mozilla.org/query.cgi search page], you can search for bugs. There is a [https://bugzilla.mozilla.org/query.cgi?format=specific simple search option] and an [https://bugzilla.mozilla.org/query.cgi?format=advanced advanced search option]. The simple search option can only be used for the simplest queries.		The tool that Mozilla uses to keep track of bugs is [https://bugzilla.mozilla.org/ Bugzilla]. With Bugzilla's [https://bugzilla.mozilla.org/query.cgi search page], you can search for bugs. There is a [https://bugzilla.mozilla.org/query.cgi?format=specific simple search option] and an [https://bugzilla.mozilla.org/query.cgi?format=advanced advanced search option]. The simple search option can only be used for the simplest queries.
	First we need to know how to look at the subset of bugs you wish to		First we need to know how to look at the subset of bugs you wish to

← Older revision		Revision as of 00:41, 3 August 2008
Line 145:		Line 145:
	* [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html Bug Writing Guidelines]		* [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html Bug Writing Guidelines]
	* [http://groups.google.com/group/netscape.public.mozilla.layout/msg/d30ce1ee477eceb0 Confirming Layout Bugs]		* [http://groups.google.com/group/netscape.public.mozilla.layout/msg/d30ce1ee477eceb0 Confirming Layout Bugs]
	* [http://~~www~~.mozilla.org/~~newlayout~~/~~bugathon.html Gecko BugAThon~~] ~~(guide to creating simplified testcases for layout)~~		* [http://developer.mozilla.org/en/docs/Reducing_testcases Reducing testcases]

← Older revision		Revision as of 06:13, 16 February 2010
Line 33:		Line 33:
	Ensuring the bugs are properly marked up helps make sure they don't get ignored.		Ensuring the bugs are properly marked up helps make sure they don't get ignored.
	For example, if a bug that really affects all platforms is marked "Solaris" because		For example, if a bug that really affects all platforms is marked "Solaris" because
	the original bug author was on a Solaris machine, most developers will ignore it		the original bug author was on a Solaris machine, most developers will ignore it because
	they need to focus on the bugs that affect the most people. If a bug is in the wrong		they need to focus on the bugs that affect the most people. If a bug is in the wrong
	component it can also get stuck without any attention. Another common issue is if		component it can also get stuck without any attention. Another common issue is if
	truly major bugs are marked normal, or have a confusing summary. ~~So, ensuring~~ that		truly major bugs are marked as normal, or if the bugs have a confusing summary. Ensuring that
	the bug is properly marked up is very helpful for getting it attention as well as		the bug is properly marked up is very helpful for getting it attention as well as
	keeping it from being ignored by appropriate queries that developers and other QAs		keeping it from being ignored by appropriate queries that developers and other QAs
Line 44:		Line 44:
	as possible. These techniques really apply to bugs QAs are filing as well.		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>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 ~~haven~~'t 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>Look for duplicates:</u> A lot of bug reporters mistakenly assume their bug hasn't been filed yet. Search for 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 more information from the reporter</u>: If you don't understand the bug or can't reproduce the bug, ask 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.<br>Some other information you could ask for:		# <u>Ask for more information from the reporter</u>: If you don't understand the bug or can't reproduce the bug, ask 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.<br>Some other information you could ask for:
	#* Does the bug occur in [http://kb.mozillazine.org/Safe_mode Safe Mode]? With a [http://kb.mozillazine.org/Profile_Manager clean profile]?		#* Does the bug occur in [http://kb.mozillazine.org/Safe_mode Safe Mode]? With a [http://kb.mozillazine.org/Profile_Manager clean profile]?
	#* If it's a crash, ask for [http://kb.mozillazine.org/Talkback Talkback data]. ([[Mozilla_QA_Community:Talkback\|more info on Talkback]])		#* If it's a crash, ask for [http://kb.mozillazine.org/Talkback 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 [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Firefox] or [http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ SeaMonkey].		#* If the reporter still can reproduce but you can't, ask him nicely if he can test a nightly build of [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Firefox] or [http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ 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 the described problem is in fact the desired behavior then mark the bug INVALID. If the bug report does not have enough information to be of any value, and requests for clarification don't net results, then resolve the bug as 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>Reproduce the bug</u>: Change the status from Unconfirmed to New if appropriate. For instance, for many Core bugs, like layout or DOM bugs, a minimal testcase is often needed 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 the described problem is in fact the desired behavior then mark the bug INVALID. If the bug report does not have enough information to be of any value, and requests for clarification don't net results, then resolve the bug as 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 dependent bug. The best resolution is 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 [http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases "How to Really, Really Help Developers on Bugs -- Minimal Testcases"] below.		# <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_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases "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.		# <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.
Line 61:		Line 61:
	# <u>Change Product, Component and owner</u>: Many bugs get marked "Firefox" when they are really bugs in the core engine. If it's a basic XUL, HTML or layout bug that affects multiple products send it to Core. After you submit a Product change to the bug, Bugzilla will allow you to change the Component as well. When changing Product and/or Component you usually want to select the radio button "Reassign bug to default assignee and QA contact of selected component ". The exception to this is when the bug is a regression and already assigned to a particular developer who caused the regression. You can spot those situations via a comment like "Joe, this appears to be from your checkin from bug 32412".		# <u>Change Product, Component and owner</u>: Many bugs get marked "Firefox" when they are really bugs in the core engine. If it's a basic XUL, HTML or layout bug that affects multiple products send it to Core. After you submit a Product change to the bug, Bugzilla will allow you to change the Component as well. When changing Product and/or Component you usually want to select the radio button "Reassign bug to default assignee and QA contact of selected component ". The exception to this is when the bug is a regression and already assigned to a particular developer who caused the regression. You can spot those situations via a comment like "Joe, this appears to be from your checkin from bug 32412".
	# <u>Add Keywords</u> -- here are just a few of the important ones [https://bugzilla.mozilla.org/describekeywords.cgi the full list of keywords is here]).		# <u>Add Keywords</u> -- here are just a few of the important ones [https://bugzilla.mozilla.org/describekeywords.cgi the full list of keywords is here]).
	#* "access": mark accessibility bugs with the keyword "access". This allows accessibility bugs to not be tied to the "Disability Access" or "Keyboard navigation" components, but to the actual component with the problem. For example, the developers for Places should really be responsible for accessibility bugs in Places, but adding the keyword "access" makes sure		#* "access": mark accessibility bugs with the keyword "access". This allows accessibility bugs to not be tied to the "Disability Access" or "Keyboard navigation" components, but to the actual component with the problem. For example, the developers for Places should really be responsible for accessibility bugs in Places, but adding the keyword "access" makes sure that those looking for accessibility bugs will also find the bug report.
	#* "regression": mark regressions with "regression". Was this ever not a bug? For example, did it work in Firefox 1.5? See below for more important information on how to deal with regressions.		#* "regression": mark regressions with "regression". Was this ever not a bug? For example, did it work in Firefox 1.5? See below for more important information on how to deal with regressions.
	#* "crash": pretty obvious :)		#* "crash": pretty obvious :)
	#* "dataloss": ~~this bug will cause~~ users to lose data		#* "dataloss": causes users to lose data
	#* "hang": freezes or locks up the application		#* "hang": freezes or locks up the application
	#* "testcase": indicates that a simplified testcase is included (see below)		#* "testcase": indicates that a simplified testcase is included (see below)