Confirmed users
14,525
edits
QA/Desktop Firefox/Walkthroughs/Iteration Development: Difference between revisions
QA/Desktop Firefox/Walkthroughs/Iteration Development (view source)
Revision as of 16:44, 7 May 2014
, 7 May 2014→General Process
| Line 22: | Line 22: | ||
Note: a demo meeting will occur the final week of the final iteration to present important features shipping in the current Nightly version. | Note: a demo meeting will occur the final week of the final iteration to present important features shipping in the current Nightly version. | ||
=== v2 Proposal === | |||
1. Reducing the volume of [qa?] triage | |||
QA believes there are some bugs which do not need to go through the [qa?] process. These bugs include work breakdowns, small UX/polish changes, and test-only changes. These bugs can be tagged [qa-] by PMs without first being tagged for QA review. QA will re-triage the [qa-] bugs once per iteration to make sure nothing is slipping through the cracks. | |||
2. Dealing with near-migration landings | |||
Some bugs will inevitably land too close to migration for QA to qualify in time. We will allow these bugs to ride the train to Aurora but they will carry over to the next iteration as a work item. If we find issues during that first Aurora iteration we will request a backout. That said, we would encourage only low-risk changes land in the last few days of the last iteration; high risk changes should wait for the next iteration to land. This is not just to ensure regressions don't sneak in but also reduces the likelihood of a risky/messy backout. As we get closer to migration landing approvals should be looked at through the lense of Aurora uplift. In other words, would Release Management approve your request for uplift if your patch was coming after migration? If the answer is ''no'' then we'd be inclined to ask you to hold off on landing the patch until after migration. | |||
== QA Commitment == | == QA Commitment == | ||