Please join Mozilla QA for a regressionwindow-wanted Bugday on Feb. 25, 2010 (9:00am PST - 3:00pm PST)

Purpose

• Teach the Mozillla QA Community how to find and address bugs with "regressionwindow-wanted" keyword requests
• As a community, significantly reduce the number of open "regressionwindow-wanted" requests for Firefox product

How to get involved

• Join irc.mozilla.org #bugday (Say hello, tell us you're there to help)
• Be ready to be handed a bug to investigate. Even if you have no idea what to do, someone will walk you through the process, if you need it.

What to do

"regressionwindow-wanted" is a keyword that says "This bug is a regression, and would strongly benefit from someone narrowing down the time period where it happened, ideally to a specific checkin." Here is the list of bugs we'll be working on for this bugday:

Confirmed bugs with regressionwindow-wanted keyword

It is a list of confirmed Firefox bugs for 3.5, 3.6 or trunk. So you'll have to let us know if we give you a bug that you don't have a version of. That also applies to OS specific bugs.

The list isn't very long. However, each one can be time consuming. So here are some helpful tips to get you headed in the right direction.

Nightly builds If you need them, much older builds are filed by the year then month.

• First, read through the bug so you understand how to reproduce the bug and understand what the expected behavior is.
  • If the regression window has already been found (or a fix proposed), simply remove the keyword and move on. (yep, sometimes the keyword is not removed once the issue has been addressed.)
  • If the work has not been done, this is where the fun begins.
• Make sure you can reproduce the problem with a current build on the specified platform (if the bug is platform specific)
• Now comes the time consuming part. We'll be installing various builds, running the step to reproduce the bug, until we determine the regression window.
  • First select a build that is a full point release older than the time frame the bug was filed. For instance, if the bug was filed just before 3.5.6 was released, check if the bug was in the 3.5.5 release.
    • if the bug was in the 3.5.5 release, then you have to go back to an even older build. In this case, I'd recommend taking a big jump back to say 3.5. Keeping going back to older and older builds until you find one where the bug doesn't exist.
    • if the bug wasn't in 3.5.5, you now have a place to start binary regression testing.
• Once you have a failed build (usually the one the bug was filed against) and a build that doesn't exhibit the bug you can start perform what we call a binary search to narrow down the regression window.
  • Simply split the difference in time from the good to the bad build and install a build from that date.
    • If the build you test has the bug, then split the difference from that build date to the working build date again.
    • If the build you test doesn't have the bug then split the difference from that date to the failed build date.
  • Continue splitting the difference in build dates until you have a one day regression window. Always move back in time after a buggy build and move forward in time after a not buggy build. The moves should be half the time between the closest known buggy build and closest known not buggy build (note: it really helps to write down the build dates you test and its status (Pass/Fail or Bug/NoBug) so you can track where to move to next.
• One day regression windows are usually enough for the developers to determine which check-in caused the bug. Once you've found that regression window post to the bug the build ID's of both the passed build and the failed build. Then remove the regressionwindow-wanted keyword.

See you in #bugday,

Tracy

Mozilla QA

Bugday Stats

• Starting bug count - 13
• Ending bug count - ??
  • (goal: at least a 75% reduction in regressionwindow-wanted requests from this list)

• Active Participants - ??
  • Community - ??
  • Moz QA - ??

• Actions taken: