Quality Process at Mozilla

[baa...@g.rit.edu]

Dear Mozilla QA team,

We are students at Rochester Institute of Technology who is conducting a research on how open source projects community ensure quality in their software. Therefore kindly, I have the following questions that I need your help guys to answer them:

1) How is the QA process looks like?
2)Is there a board or a committee called "commiters within the mozilla projects to impose QA for each solution within the project"?
2)How do you perform test for specific component/release?
3)After a bug or a new feature been added by the community how Mozilla ensure it is valid and can commit it to the product repository?

Thank you and sorry for interruption guys..

Regards,
Bandar Alsaif

[Stephen Donner]

Hi Bandar -


1. The QA process varies among the different teams - if you follow up with a few more specific questions, I can at least tell you what our team, Web QA, does, on the whole (but even then, it differs between the various projects, slightly)
2. There is no such board or committee, no - individual contributors, both paid and community, are empowered to work with developers and the product/project management teams to iterate on a process and workflow that works for that project, typically. There are, usually, leads, and of course management as well, who help set guidelines, but we're not very top-down.
3. Again, specifics will sometimes change wildly among projects, so it's very hard to generalize, even at a high level.
4. Typically, regardless of whether it's desktop Firefox, a Web project, mobile Firefox, etc., we (Mozilla) expect that developers are writing and running unit and/or integration tests against their builds/applications, and QA works with developers to help define coverage types and strategies (automation, manual testing, etc.) as well as risk-assessment -- we then will try to continually assess and fill in testing-coverage gaps, according to time/ability, and risk.


Briefly, though, it typically follows a pattern (best-case scenario) like so:


* developer commits a fix or feature, along with (hopefully) a unit and/or integration test
* some sort of visible automation suite (typically continuous integration -- i.e. buildbot or Jenkins, etc.) runs and reports status of the committed fix/feature
* QA team/community gets access to a build (binary for client code, or development/staging URL, for Web projects), hopefully tests the specific fix/feature , and, additionally, would do exploratory/ad-hoc and/or guided testing around that feature and things it could potentially break/regress
* QA team/community either verifies the fix or reopens it, in which case...
* the above 4 steps would be repeated
* once the fix is verified, it typically gets committed/merged to a higher-level branch (and also typically reaches a wider audience, especially in the client world, where we have trunk/nightly -> aurora -> beta -> release builds of Firefox on various platforms)
* additional levels of testing tends to happen at "staging" or "release" branches -- i.e. right before we push the code live to "production" or make a final, shipping version of Firefox
* there's lots more, of course - Firefox has a Beta program where thousands of testers help us find and determine risk/impact of regressions, before we ship that final version


I and others would happily answer more specific questions -- per team and/or project/product might be best; "testing" and "quality" at Mozilla is a broad swathe that thankfully involves more than just the QA side of this organization.



Cheers,


- Stephen

----- Original Message -----

_______________________________________________
dev-quality mailing list
dev-q...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-quality
_______________________________________________
QA mailing list
Q...@mozilla.org
https://mail.mozilla.org/listinfo/qa