Webtools/Checklist

Purpose of this Document

The aim of this document is to serve as a set of guidelines, implemented in a checklist format, to which parties launching web marketing campaigns can easily refer as they move the project from concept to a quality, successful, and timely launch, with the assistance of Web Development, IT, and QA.

Checklist before a Hand-off to QA/WebDev/IT

1. Have IT, WebDev, and QA been given advance notice?
2. Who is the intended user-base?
   
   1. What level of traffic is/are the page(s) expected to generate?
3. What happens in the JavaScript-disabled case? (Is functionality lost? Are there layout issues?)
   
4. What level of support does this project have on non Firefox-based browsers?
   
5. Have the appropriate Accessibility accommodations been made?
6. Does this project need metrics/tracking code?
   
7. Is it code-complete at hand-off, or will it need work from Web Development (CSS fixes, link populating, etc.)
   
8. Is this project tied to a specific hard date, or coinciding with a product release?
9. Have any potential partners been notified of the rollout?
10. Is there a contingency/roll-back plan put in place?

I think the design work is ready to be tested; what's next?

1. Double-check (if you're able) that you've considered the issues in the checklist, or know whom will address them
2. If the project already has a Bugzilla component, file a bug there, assigning it to the appropriate QA contact (if in doubt, email qa-execution@mozilla.org with the bug # and background)
   1. If the project has no such component, please file in the "Websites" product, under the "www.mozilla.com" component.
   2. In the bug, note any contingencies/dependencies
   3. Be clear as to what work is already completed, what will eventually need to be pushed where and when (the actual call to push is a separate bug), and what still needs to be implemented
3. QA and WebDev will investigate whether the project is testable, and if so, QA will write a test plan incorporating a testing approach, support for various browsers, and staging URLS.
4. QA will then note the testing results--depending on the amount and types-- either directly in the bug or in the test plan (usually both)
5. An empowered member of Marketing (usually they who are leading the project) will--after consulting with QA/WebDev/IT--make the call as to whether to ship
6. Marketing will file an IT ticket asking that the approved changes be pushed to production

Contacts

QA

Stephen Donner stephend@mozilla.com

Web Development

Wil Clouser clouserw@mozilla.com
Mike Morgan morgamic@mozilla.com