Releases/Firefox 39/Test Plan

From MozillaWiki
Jump to: navigation, search

Summary

This page is to track testing of Firefox 39 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-02-23 Conduct daily stability and bug triage, ensure features are owned
Aurora Migration 2015-03-30 Conduct testing to ensure Firefox 38 Aurora builds are okay, sign off for updates on Friday
Aurora Updates enabled 2015-04-03 Continue daily stability and bug triage, ensure features are tested
Beta Uplift 2015-05-11 Review testing and sign off every beta release
Release 2015-06-30 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 39 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.

During the 39 Nightly cycle we will be working to help determine the state of the Electrolysis (e10s) project. e10s will be ready to move to Aurora if all bugs marked with tracking-e10s:m6+ and lower are fixed in Nightly.

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 39:
  • Bugs fixed / verified on 39:
  • Conditional signoff for merge: (date, who signed off)
  • QE signoff:

Aurora

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

  • 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] Automation - document all Mozmill test failures (on functional tests) and memory usage regressions (on endurance tests - note that those are only run on nightly, so you look for regressions that happened there). Bugs for those are usually filed by the automation team, but check that they are on top of that.
  • [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):

  • [DONE] MM-CI - configure the mozilla-aurora_update testrun on MM-CI to use the aurora channel
  • [DONE] 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

  • Build 1 should be available May 21st some time in the morning.
  • Build 1 doesn't need update tests. We will do them for build 2!
  • Manual testing
  • build1: changeset:31d67ade8354 (build ID: 20150520170903)

Testing

For Build 2

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

Release Candidates

39.0 build3

Build Information

Testing

  • Automated (configs for ondemand)
    • This is the 39.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)

39.0 build4

Build Information

Testing

  • Automated (configs for ondemand)
    • This is the 39.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)

39.0 build5

Build Information

Testing

  • Manual
  • Automated (configs for ondemand)
    • This is the 39.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)

39.0 build6

Build Information

Testing

  • Automated (configs for ondemand)
    • This is the 39.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 39.0

Build Information

  • See Release Candidate Build 6

Testing

  • Update Testing - see Release Candidate Build 6
  • Throttle Testing (see Walkthrough for details)
    • Used commands:
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/38.0.5/20150525141253/WINNT_x86-msvc/en-US/release/Windows_NT%206.3/default/default/update.xml
./throttle.sh https://aus3.mozilla.org/update/3/Firefox/38.0.5/20150525141253/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/38.0.5/20150525141253/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/38.0.5/20150525141253/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-07-02: Win32: 25% - Mac: 25% - Linux32: 23% - Linux64: 24%
      • After disabling updates (expected to be @ 0%), omitted
      • After fully enabling updates (expected to be @ 100%), 2015-07-08: Win32: 100% - Mac: 99% - Linux32: 100% - Linux64: 100%

39.0.3 build2

Build Information

Testing

Retrieved from "https://wiki.mozilla.org/index.php?title=Releases/Firefox_39/Test_Plan&oldid=1088883"