QA/Desktop Firefox/Walkthroughs/Iteration Development
< QA | Desktop Firefox | Walkthroughs
Iteration Development
The Firefox development team follows a two-week iteration cycle to land fixes on mozilla-central (aka Nightly).
General Process
- The Desktop Management Team (Gavin, Chad and Madhava) review the Product Backlog and create a prioritized list of work for the upcoming iteration.
- 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.
- Tuesday, Desktop Project Managers distribute the current iteration assignments to the QA contract responsible for the current release cycle (Anthony, Tracy, or Juan).
- Wednesday, a QA triage session is held to determine which bugs need testing and to ensure those bugs are assigned to QA Contacts.
- As bugs selected for testing are resolved they are tested by the assigned QA Contacts.
- The following Tuesday, a status meeting is held for all teams to review the status of the selected work.
- 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.