QA/Execution/Web Testing/Project Checklist: Difference between revisions

→‎Project/release-cycle: Adding optimal bugflow workflow
No edit summary
(→‎Project/release-cycle: Adding optimal bugflow workflow)
Line 82: Line 82:
#Are the third-party developers cc:d on all relevant bugs?  If possible (i.e. not "mozilla-confidential" flagged), have them follow the Bugzilla component (and make sure they have accounts).
#Are the third-party developers cc:d on all relevant bugs?  If possible (i.e. not "mozilla-confidential" flagged), have them follow the Bugzilla component (and make sure they have accounts).
#Has a push bug, and a release checklist, even if you don't think they need it (they do)
#Has a push bug, and a release checklist, even if you don't think they need it (they do)
== Optimal Bugzilla Workflow ==
Each project can be different, but please use this flow if starting a new project:
* A bug is filed in the correct product/component
* Bug is triaged for severity, priority and assigned to a target milestone
* Bug is fixed in work based on next target mileston release
* Dev marks bug CLOSED:FIXED
* Tester verifyies bug on stage, bug marked CLOSED:VERIFIED
* Code is deployed to production
* Tester verifies bug
* Tester verifies deployment
Whiteboard may be used for various reasons:
* [good first bug] - Communicates a contributor opportunity


=Site Config=
=Site Config=
Confirmed users
1,136

edits