Releases/Firefox 42/Test Plan

From MozillaWiki
Jump to: navigation, search

Summary

This page is to track testing of Firefox 42 from mozilla-central (Nightly) through to mozilla-release. This is intended to be a minimal set of information to help Firefox QA understand and communicate the quality of upcoming releases. Our current walkthrough of the release and QA process might be changing due to recent reorgs.

Schedule

Please consult the Rapid Release Calendar for more information.

Milestone Date Checks
Nightly 2015-06-29 Conduct daily stability and bug triage, ensure features are owned
Aurora Migration 2015-08-10 Conduct testing to ensure Firefox 42 Aurora builds are okay, sign off for updates on Friday
Aurora Updates enabled 2015-08-14 Continue daily stability and bug triage, ensure features are tested
Beta Uplift 2015-09-21 Review testing and sign off every beta release
Release 2015-11-03 Review tests and sign off release

Meetings

Meeting Purpose When Vidyo Room IRC Backchannel
Channel Status Raise quality concerns with the Release Management team 10:00 Pacific on Tuesday & Thursday ReleaseCoordination #planning
Firefox QA Meet the Desktop QA team and hear what they're working on 8:30am Pacific on Wednesdays DesktopQA #qa
QA Team Meet the entire QA team and hear what they're working on! 1:30am Pacific on Wednesdays QA #qa

Nightly

During the 6 weeks that Firefox 42 is on the Nightly channel, QA will focus on helping with the Firefox iteration planning, as well as with crash reporting and triaging newly reported bugs. The earlier we can get these bug reports into shape for developers to prioritize them and work on them, the more likely they'll be fixed by release in April.

Reference: https://wiki.mozilla.org/QA/Desktop_Firefox/Walkthroughs/Release_Coordination#Nightly

Questions for workweek
  • Each topcrash should have a developer assigned, a QA contact, and tracking + or -.
  • We should decide on a threshold for "crisis" level crash spikes/crash rates. (Different for startup, plugin, crashes or specific platforms)
  • What do we want to do with the iteration process. Continue assigning QA contact, verification + or -?
  • We should encourage the use of "feature" or verification needed keywords/flags.
  • What, if any, conditions would actually block or delay the move to aurora?
End of cycle status
  • Total bugs filed affecting 42:
  • Bugs fixed / verified on 42:
  • Conditional signoff for merge: (date, who signed off)
  • QE signoff:

Developer Edition (Aurora)

Continue triaging incoming bugs with community help. Test e10s issues.

During the 42 Developer Edition cycle we will be working to help determine the state of the Electrolysis (e10s) project. e10s will be ready to move to Beta if stability and fixes are up to an acceptable quality level.

  • File crashes, escalate bad crashes.
  • Track feature milestones (for example the e10s tracking flags.)
  • Should have testing plans for features that we know may be turned off /on conditionally.
  • link to release notes. review & update.

Reference (and migration / signoff plan: https://wiki.mozilla.org/QA/Desktop_Firefox/Walkthroughs/Release_Coordination#Aurora)

Beta

During the Beta cycle, there are at least 9 beta releases. Communication with the release coordination, release engineering, and automation teams is key.

QA analyzes the results of functional, remote, and update tests running on jenkins. We create config files for the update tests, check their validity on mciconf and run them on at least two channels for each beta release cycle. A big part of this work currently is going through the test results to figure out why test failures occurred (infrastructure, tests themselves, actual Firefox bug).

Pivotal bugs may need verification during each beta cycle.

  • link to release notes. review & update.
  • crash evaluation/escalation.
  • feature evaluation.

QA Activities

QA wanted

The following tracks bugs which have requests for urgent QA assistance.

  • Choose a bug to test from the list below
  • Read it and make sure you understand what information is needed (this may be steps or URLs to reproduce, a regression range, or something else altogether)
  • Use the latest build of this Firefox version and test until you've discovered the information necessary. Ask for help if you need it.
  • Report this information to the bug and remove the qawanted keyword

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


Stability

This section tracks bugs representing the most urgent stability issues. Consult this wiki for more information.

  • Ensure new and explosive crashes have actionable bug reports which are in progress
  • Top Crashes - ensure the highest ranked crashes have actionable bug reports which are in progress
  • Untriaged Bugs - ensure bugs are actionable and in the correct component
  • topcrash bugs

Unconfirmed Bug Triage

The following tracks triage and testing of incoming, unconfirmed bug reports.

  • Choose a bug to test from the list below
  • Use the latest Nightly build to confirm the bug reproduces
  • Flag with reporter with needinfo if you cannot reproduce and need more information
  • Set the status to NEW and ensure the bug is in the appropriate component if you can reproduce the bug (provide as much detail about your testing as possible)
  • If it's a Firefox bug you may want to add the firefox-backlog=? flag to it.

Queries:

Verification Needed Bugs

  • Review the bugs below in the Pending Triage section and select a bug you want to test
  • Make sure you understand the bug before you begin testing it
  • Test on a previously known broken build to make sure you can reproduce the bug
  • Test on the latest build from the branches which are fixed to confirm the bug no longer reproduces
  • Mark the bug VERIFIED FIXED if the bug appears to be fixed and set the appropriate status-firefox flag to verified
  • Reopen the bug if it still reproduces

Iteration Development

Firefox development during Nightly works on two-week iterations as of 2014. This section tracks the bugs selected for development in these iterations. Please consult the Iteration Dev Walkthrough and the Firefox/IterativeDevelopment page for more information on this process.

  • Ensure all bugs are marked qe-verify:+ or -
  • Ensure all qe-verify:+ bugs have a QA Contact (The Feature Owner page may help here)
  • Ensure all selected bugs are VERIFIED before the end of the iteration
  • Anything incomplete at the end of the iteration will be automatically carried over to the next iteration

Queries:

Milestones

Aurora Migration

Post-merge Work (as soon as updates are disabled):

  • [DONE] MM-CI - configure the mozilla-aurora_update testrun on MM-CI to use the auroratest channel (before first Aurora builds are generated)

Pre-sign-off Checks:

  • [DONE] Features - all scoped features are signed off as ready for Aurora by owners. (If you haven't heard anything to the contrary, that is probably true, but make sure we don't know of blocking issues.)
  • [DONE] Bugs - document and review any reported bugs and issues, nominate them for tracking if serious (i.e. make sure all bugs needed to be tracked have at least a request for that up).
  • [DONE] Stability - review crash stats before sign-off to raise any red flags.
  • [DONE] L10n - contact L10n drivers (usually :Pike) to see if there are any known localization issues.

Post-sign-off Checks (as soon as updates are enabled again):

  • {{|}} MM-CI - configure the mozilla-aurora_update testrun on MM-CI to use the aurora channel
  • {{|}} Updates - previous versions of Aurora update to the new version (check a few old builds manually once next round of new builds is available)

Betas

Beta 1

Build Information

Testing

Beta 2

Build Information

Testing

Beta 3

Build Information

Testing

Beta 4

Build Information

Testing

Beta 5

Build Information

Testing

Beta 6

Build Information

Testing

Beta 7

Build Information

Testing

Beta 8

Build Information

Testing

Beta 9

Build Information

Testing

  • Automated (configs for ondemand)
    • [SKIPPED] Updates on beta-cdntest channel (report)
    • [SKIPPED] Updates on beta channel (report)
    • Due to brokenness of mozdownload caused by "FTP" (archive.m.o) server changes, only manual spot-checks were performed.

Release Candidates

Build 1

Build Information

Testing

  • Automated (configs for ondemand)
    • This is (supposedly) the 42.0 release build. We should test updates on beta-cdntest for a preliminary sign-off (Release Management must give the "go" for pushing to beta), then on beta after the push to beta, and then on the day before release (Monday), after a full sign-off and push to that channel, run tests on release-cdntest.
    • [DONE] Updates on beta-cdntest channel (report)
    • [DONE] Updates on beta channel (report)
    • release channels skipped due to build2.

Build 2

Build Information

Testing

  • Automated (configs for ondemand)
    • This is (supposedly) the 42.0 release build. We should test updates on beta-cdntest for a preliminary sign-off (Release Management must give the "go" for pushing to beta), then on beta after the push to beta, and then on the day before release (Monday), after a full sign-off and push to that channel, run tests on release-cdntest.
    • [DONE] Updates on beta-cdntest channel (report)
    • [DONE] Updates on beta channel (report)
    • [DONE] Updates on release-cdntest channel (report)
    • [DONE] Updates on release channel (report)

Release 42.0

Build Information

  • See Release Candidate Build 3

Testing

  • Update Testing - see Release Candidate Build 3
  • Throttle Testing (see Walkthrough for details)
    • Used commands:
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/41.0.2/20151014143721/WINNT_x86-msvc/en-US/release/Windows_NT%206.3/default/default/update.xml
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/41.0.2/20151014143721/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2013.4.0/default/default/update.xml
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/41.0.2/20151014143721/Linux_x86-gcc3/en-US/release/Linux%203.13.0-45-generic%20%28GTK%202.24.23%29/default/default/update.xml
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/41.0.2/20151014143721/Linux_x86_64-gcc3/en-US/release/Linux%203.16.0-30-generic%20%28GTK%202.24.25%29/default/default/update.xml
    • Results
      • After release push (expected to be @ 25%), 2015-11-03: Win32: 23% - Mac: 23% - Linux32: 24% - Linux64: 26%
      • After disabling updates (expected to be @ 0%), 2015-11-04: Win32: 0% - Mac: 0% - Linux32: 0% - Linux64: 0%
      • After fully enabling updates (expected to be @ 100%), 2015-11-06: Win32: 100% - Mac: 100% - Linux32: 100% - Linux64: 100%
Retrieved from "https://wiki.mozilla.org/index.php?title=Releases/Firefox_42/Test_Plan&oldid=1104619"