What is Quality To a QA Engineer?
Test and Monitor | Posted February 21, 2013

We talk a lot about the importance of quality products. But what does the word "quality" really mean? Is it a subjective or objective trait? And how can anyone strive to achieve high quality without first understanding what that term actually entails? Over the next few weeks, we invite you to join us as we explore the meaning of the word "quality," and try to understand the role it plays in our everyday lives. With this post, we get the perspective of a person who literally has "quality" in their title: A quality assurance engineer.

If you are a QA engineer, you may - at some point - ask the question, "what is software quality?" Does your definition influence your ability to recognize true quality?

Before you answer, maybe it's easier to decide what you think the term "quality" means in the grand scheme of things. What makes a quality person? What makes a quality smartphone? What other aspects of your daily life do you think exemplify quality? Do you see a pattern in what you deem to be high, or low, quality?

Now throw all of that perception away, because as a QA your opinion has little or no meaning in the development process.

As a quality assurance engineer, you learn very quickly that quality is objective - or, at least, that you must think of it that way. Your perception of quality rarely comes into play, and when it does it usually does not work in a product development environment - by this point brainstorming is over and the concept is on the table.

You may have already noticed that I used the term “perception of quality,” leading you to think that I actually mean quality is subjective. You’re quite correct. Quality is subjective, only not in a product development environment. If quality was subjective in the development process, everyone would have their own idea as to what needs to be done to create a quality product, inviting project chaos.

This is why we utilize spec sheets and listed functionality. By the time a QA gets involved, the product has already been created on paper. Meeting those criteria is what will make a high quality product, at least in the eyes of your development team. On the flip side, a low quality product is simply one that does not meet the criteria that we're given.

It's also important to point out that there is different levels of quality, and deciding whether something is of high or low quality is half the battle. What about a product that is only of medium quality?

For instance, the product designer sends you a spec sheet stating that the product must play MP3 files. Firstly, this is not up for interpretation. The product is to include the functionality of MP3 fields because all other competitor products do so, and your product would immediately fall behind if it did not.

So we understand that the product needs to play MP3 files, but the functionality listed does not specify which types of MP3 files - e.g., MP3 files with higher bit rates. If the product plays MP3s at 96kbps but not at 128kbps, both being popular bit rates, the quality of this functionality would be considered lacking.

Therefore, quality in a development environment is to meet all listed functionality as a whole, but also to meet a high standard of quality for each function.

Now that you understand, at least my interpretation of quality in a development environment, let's take a look at how you achieve that quality:

  • When deciding what to build a test case for, refer to the product guidelines, such as, required features and/or spec sheets.
  • Your opinion is valuable but must be presented in brainstorming sessions. Time is of the essence and too much jibber-jabber can send a team off course and waste time.
  • Be persistent in what is required of the developer, and work with them to create a schedule to ensure that bug fixes happen in a timely manner.
  • Always make sure you are able to reproduce a bug before requesting a fix from the developer, and find a tool that easily can track defects and build bug history. 

Fellow QAs, what do you think? What other steps can be added to my list above to ensure that the product you put out is of the highest possible quality? Do you think "quality" really is a subjective term? Check back next week to see Niclas Reimertz's argument that quality is an entirely objective attribute.

See also:


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox