Quality Assurance (QA) Glossary

Last modified: August 4, 2002.

The Mozilla project inherited a lot of its quality assurance methodologies and terminology from Netscape, the originator of the project. This glossary attempts to list some of the often used quality assurance terms.

This glossary is a work in progress - not all terms have explanations yet.

• Code Review
  When a volunteer submits his/her code to Mozilla, before it can be incorporated into the product, it needs to be checked. Code submissions are checked twice:
          Review (shorthand: r= ) - The first approval is called a Review
          Super Review (shorthand: sr= ) - The second one is called Super Review
• Bonsai
• Bugzilla - A web based tool ( http://bugzilla.mozilla.org )which keeps track of bugs found (and fixed) in Mozilla. Bugzilla is also used by many other organizations besides Mozilla.org, and has its own website at : http://www.bugzilla.org . Bugzilla's comment system (similar to a bulletin board)  is often used for discussions about certain problems / issues.
• Daily (nightly) builds - Versions of Mozilla which are produced every day, based on contributions/improvements made on that day.
• Developer to tester ratio - The ratio of developers to software testers.
• "Eating your own dogfood" - using a program developed by yourself or co-workers.
• Five categories of bugs. When a bug is filed in Bugzilla, it is categorized into one of five categories:
          critical
          major
          normal
          minor
          trivial
• Full Circle Talkback - A program which is bundles with most versions of Mozilla (and Netscape) which records certain information after a crash has occured. This program offers to transmit the information captured by this program to Mozilla developers, so they can fix the cause of the crash.
• Localization - Translation of the user-interface into another language .
• Milestones - An especially stable version is known as a milestone. Historically, Mozilla milestones have appeared every 6 weeks or so, but after the release of Mozilla 1.0, this period has been extended to 18 weeks or so.
• Smoke tests - tests performed on software to ensure that newly added features have not caused older features to malfunction.
• Tinderbox
• The stabilization phase - During this phase of software development, no new features are added; instead all effort is concentrated on making the software reliable - i.e. making sure it does not crash. (For example: There was a stabilization period before the release of Mozilla 1.0.)
• Quality Assurance (QA) - Tests performed to ensure that software performs as it was designed to.
• Release Candidate - A pre - release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).
• Usability Testing
  Tests often performed on "normal people", to see if the features added to a program are as intuitive and easy to use as the developers thought they were. Usability testing ensures that software is *usable* - not only by the programmers who wrote it, but also by "ordinary" / "normal" people.