For a long time, I’ve led the automation team at Mozilla. This past fall, I took on the job of leading the QA team as well. I don’t really like the term “QA.” Technically, it means “Quality Assurance.” It’s a term borrowed from industrial settings where you actually have quality inspectors (maybe you’ve seen tags that say “quality inspected by inspector 31” on products) that assure a certain level of quality by inspecting a relevant sample of products as they come off the assembly line/factory floor.
In software, while there is a product, a release of that product is actually only a draft of a set of code at a particular point in time. The draft continues to be revised and to evolve for the lifetime of the product. The code that comprises Firefox 30 is largely the same code that is going to be Firefox 31, but there will be some additions and deletions. This, in a very simplistic sense, is what releasing software is all about.
So, this idea that anything is ever “finished” is a misnomer. The idea of a “completed” product is more or less false–a released product can be considered a completed package of code, and in that sense, we can analyze its quality on several metrics. But, due to the iterative nature of software development, it makes a lot more sense for a quality team to be focused on each of those iterations and to be involved in the engineering work alongside the teams wrestling with that code. This is where the term “Quality Engineering” comes from and describes far better what actually happens on a day to day basis. Finding issues with that code early and often results in a much higher bar of quality when the time comes to release that code.
Quality is also maintained by automated testing, which was always the first job of Mozilla’s automation team. The automated testing system at Mozilla catches several hundred issues a month and ensures they are addressed before any human ever installs that code.
Because it’s hard to change habits, I don’t expect anyone at Mozilla to stop referring to the quality team as “QA.” But, I will redefine those letters to stand for Quality and Automation.
Why do these kinds of silly definitions matter?
Because what you articulate is what you build. I want to move away from the passiveness of “assessment.” I want to move away from reviewing things that have been done to reviewing things that have yet to be. I want to see a team that is more proactive and less reactive. I want to help this team realize its own dream of engineering quality into the product by helping it use a more technical lens in its reviews and planning, by making better use of automation, by being more involved earlier in the iterations, and by deeper and more consistent use of metrics and data analysis.
Collections of people, like code, are iterative. Real change happens in bits at a time, and is rarely easy. Nonetheless, I look forward to making these changes hand in hand with the Quality and Automation team at Mozilla.