QA/Desktop Firefox/Walkthroughs/Stability: Difference between revisions

Line 21: Line 21:
* Bugs which have been marked ''affected'' for several days should be updated with the latest data from [https://crash-stats.mozilla.com/ Socorro] and either flagged for QA or Engineering support as required
* Bugs which have been marked ''affected'' for several days should be updated with the latest data from [https://crash-stats.mozilla.com/ Socorro] and either flagged for QA or Engineering support as required


== Intructions for QA Leads ==
== Test Plan Template ==
The QA Lead is responsible for tracking and escalating the most serious crashes to developers and release managers, and ensuring issues remain on track.
Topcrash Bugs ([[Releases/Firefox_31/Test_Plan#Topcrash_Bugs|live example]]):
 
1. Make sure you attend the meetings to communicate and discuss the most critical issues needing attention.
 
2. Add a section to your test plan to track top crash bugs using the following syntax ([[Releases/Firefox_31/Test_Plan#Topcrash_Bugs|live example]]):
<pre>
<pre>
<bugzilla>
<bugzilla>
{
{
  "include_fields":"id,summary,cf_status_firefox31",
  "include_fields":"id,summary,cf_status_firefoxNN",
  "keywords":"topcrash",
  "keywords":"topcrash",
  "f1":"cf_status_firefox31",
  "f1":"cf_status_firefoxNN",
  "o1":"nowordssubstr",
  "o1":"nowordssubstr",
  "v1":"--- verified",
  "v1":"--- verified",
Line 42: Line 38:
</pre>
</pre>


3. While optional, I like to also include a list of all crash bugs (([[Releases/Firefox_31/Test_Plan#Crash_Bugs|live example]])
Crash Bugs ([[Releases/Firefox_31/Test_Plan#Crash_Bugs|live example]]):
 
<pre>
4. Familiarize yourself with the [[CrashKill/Topcrash|topcrash criteria]] if you have not done so already
<bugzilla>
 
{
5. Every day, check the [https://crash-analysis.mozilla.com/rkaiser/0000.overview.html explosiveness report]
"include_fields":"id,summary,cf_status_firefoxNN",
* Signatures which show up as <span style="color:red">'''red'''</span> are deemed explosive and need to be reported in Bugzilla
"keywords":"crash",
* If an explosive signature is already reported then report it's explosivness in the bug
"f1":"cf_status_firefoxNN",
* While lower priority, it's also useful to report new signatures (those which first appear recently) even if low volume
"o1":"nowordssubstr",
 
"v1":"---",
6. Every day, check the [https://crash-stats.mozilla.com/topcrasher/products/Firefox topcrash report]
"f2":"op_sys",
* Signatures at the top of the list without a bug report should be reported (anyting in the top-20 usually)
"o2":"nowordssubstr",
* Signatures which have moved more than a couple of positions should have their information updated in Bugzilla
"v2":"Android Gonk"
 
}
7. Every day, review the topcrash bug list for ''fixed'' bugs
</bugzilla>
* Any bug which has been fixed for at least 3 days should be reviewed
</pre>
* Check crash-stats to see if the fix has had an impact
* Look for the movement in the topcrash report
* Also look at the product correlations in the crash reports to see if there are instances of the crash with newer builds
* REOPEN the bug if there are crashes with that signature in post-fix builds
 
8. Every day, review the topcrash bug list for ''affected'' bugs
* Any bug which has not been updated in a few days should have it's crash-stats updated
* See if there's any new information in the bug QA could use to narrow down a cause
* If you think QA can assist, add the ''qawanted'' keyword to the bug and assign a QA Contact (Florin Mezei if you are unsure)


== Instructions for Testers ==
== Instructions for Testers ==
Confirmed users
14,525

edits