Software testers are preoccupied with the concept of quality, which makes complete sense because our jobs are to ensure that only quality software goes out the door. Unfortunately, quality is a somewhat ambiguous term that will vary depending on the industry, environment, company culture, product line, and pretty much anything else you can imagine. Even the ISTQB definition (at the ISEB/ISTQB Foundation level) is not applicable across-the-board.
So this begs the question: what exactly is quality? Can we come up with some sort of standardized definition? Well, before we can answer that question, let’s first identify some of the more common viewpoints of this.
Some people will say that quality correlates with the reputation of the brand. Big companies with well-known brands are often perceived to deliver higher-quality products. After all, with access to all those resources surely they can ensure the highest quality possible, right? The problem with this definition is that it is subjective and will depend on each individual’s perceptions, expectations, and preconceived notions regarding the brand. Since this is not quantifiable, it is not measurable and therefore is a poor definition of quality in the context of software testing.
Another view holds that quality relates to perfection. In other words, a software application with no identified bugs is often said to be of quality. Unfortunately, although this sounds nice, a zero-defect application is generally not something we find in the real world. Usually, you wouldn’t be testing 100% of the code because there are diminishing returns in doing this. Some people refer to this as the “fallacy of exhaustive testing.”
There are other views as well, but hopefully you get the point. The bottom line is that any definition of quality should be specific, measurable, and realistic. Therefore, in my view at least, the best definition of quality is that the product meets the requirements around the product’s attributes, features, and functionality. This seems like the best viewpoint because it defines specific indicators which are testable and measurable. You test a requirement, and the software either executes it properly or it doesn’t. It really doesn’t get much clearer than that!
Filed Under: Software Testing