QA/Desktop Firefox/Walkthroughs/Iteration Development

< QA‎ | Desktop Firefox‎ | Walkthroughs
Revision as of 16:49, 15 April 2014 by Ashughes (talk | contribs) (Created page with "= Iteration Development = The Firefox development team follows a two-week iteration cycle to land fixes on mozilla-central (aka Nightly). ==...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Iteration Development

The Firefox development team follows a two-week iteration cycle to land fixes on mozilla-central (aka Nightly).

General Process

  1. The Desktop Management Team (Gavin, Chad and Madhava) review the Product Backlog and create a prioritized list of work for the upcoming iteration.
  2. Tuesday, a planning meeting is held for all teams to review and select bugs to be completed in the iteration. Anything that is not selected stays on the backlog for a future iteration.
  3. Tuesday, Desktop Project Managers distribute the current iteration assignments to the QA contract responsible for the current release cycle (Anthony, Tracy, or Juan).
  4. Wednesday, a QA triage session is held to determine which bugs need testing and to ensure those bugs are assigned to QA Contacts.
  5. As bugs selected for testing are resolved they are tested by the assigned QA Contacts.
  6. The following Tuesday, a status meeting is held for all teams to review the status of the selected work.
  7. At the end of the two-week iteration, all selected bugs should be resolved and tested as needed. Any work that is incomplete or not yet tested will be carried over to a future iteration.

Note: a demo meeting will occur the final week of the final iteration to present important features shipping in the current Nightly version.

QA Commitment

QA will...

  • triage all bugs selected for work at the beginning of the iteration to identify work needing testing
  • ensure all bugs selected for testing are promptly assigned a QA Contact
  • ensure all bugs selected for testing are thoroughly tested upon resolution
  • not test any bugs deselected for testing unless a special request is made
  • not test any bug before it is RESOLVED unless a special request is made

QA Methodology

QA will use the following whiteboard tags to categorize bugs based on testing necessity:

  • [qa+]: a bug that has been tagged for testing in the iteration
  • [qa-]: a bug that has been tagged as not needing testing
  • [qa?]: a bug that has been tagged as unclear and needing follow-up information before we can make a testing decision

When QA has completed testing we will mark the STATUS of the bug in one of two ways:

  • REOPENED if any issues are found (more on this below)
  • VERIFIED FIXED if no issues are found

QA Contact:

  • to be used to assign responsibility of testing to someone within QA.

When a FIXED bug has issues

  • Once a bug is resolved it is the responsibility of the QA Contact to ensure the bug is thoroughly tested.
  • If issues are found during testing they will be reported to the bug and that bug will be REOPENED.
  • It will be the Assignee's responsibility to determine if that work is in or out of scope.
  • If the issues are determined to be in-scope they will be addressed in that bug and retested by QA upon resolution.
  • If the issues are determined to be out-of-scope the bug will be marked VERIFIED FIXED and each of the issues will be reported by the QA Contact to dependency bugs.
  • Anything not completed before the iteration wraps up will be carried over to future iterations.