Beautiful Testing

Chapter 3. Building Open Source QA Communities

Martin Schröder

Clint Talbert

An open source project lives and dies by its volunteer base. The tinier the project, the more true that is. As we grow to use more social networks online, we have the chance to make every project, even those that were traditionally closed source, into a participatory project. We worked on the Mozilla Calendar Project, which is a project to create a calendar application based on the Mozilla Platform. We produced two products: Sunbird, a standalone calendar application, and Lightning, an add-on for the popular Thunderbird email client.

In the early days of the project, there were four volunteer developers, and two others who were paid to spend significant amounts of their time on the project. The only quality assurance (QA) that existed was one person who alternately tested new features and triaged the incoming bugs. As the code base matured, it became very apparent that we had gone as far as we could without anything but the barest minimum of QA. We decided to organize a QA Team for the Calendar Project. It took almost six months to create a viable group that was doing regular QA. It was a beautiful process, both in its most difficult periods and in its most successful.

Communication

Communication on the project was crucial. We used IRC (Internet relay chat) as our primary means of communication. In IRC, you log onto a forum and all users that are logged in there can see the conversations in real time. It ...