What is Quality To a QA Engineer?

QA Quality

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:











Comments

  1. Adam Grant says:

    You lost me at “Always make sure you are able to reproduce a bug before requesting a fix from the developer”, I find this to be a naive statement considering the modern multi-threaded runtime environment means that corner cases for race conditions may only present themselves a precious few times (if at all). To account for this, it is critical to have a comprehensive log and test artifact archive when non-deterministic problems show up.

  2. Gregory Mooney says:

    Thank you for your feedback, Adam.  
     
    You make a valid point about race conditions and I will take note of your comment because this could make for a great discussion in the future. 
     
    When I first was starting out as a software QA, I would occasionally present bugs to developers that could not be easily reproduced. This created noise in the development process. It was something I learned the hard way in the development of consumer electronics (all of which had a GUI). I felt it was worth pointing out. 

  3. I have to agree with Adam here. Even though being able to reproduce the bug is half the battle (if you can reproduce, you can locate and if you can locate you can fix) only going to a developer when you can reproduce is somewhat counterproductive. Even though it might not be reproducible 100% of the time it should still be recorded and let known to the development team so they can keep an eye out for it themselves during their own development and testing phases.

Speak Your Mind

*