Quality Is In The Eye Of The Beholder

Of the several definitions of quality found in your copy of Webster’s (or dictionary.com for those of us who haven’t opened an actual dictionary since high school), the one that I believe best fits the world of Software Testing is:

  an essential or distinctive characteristic, property, or attribute

When we test software, to assure its quality, we are ensuring that the software not only works but delivers some intended feature to the user.  For the most part, testers are able to verify their findings against an established spec or meeting notes or some form of outline that will tell them if the software passes and, as a result, delivers on the intended feature.  However, often the case is that the test findings will result in questions as to whether the actual software features and the intended features are a match.  Thus begins the questions; Is it a bug, an undocumented feature or a complete misunderstanding between the developers and the stakeholders?

Oh the joys of Software Testing!

At this point, it might be helpful to look at two additional definitions of quality;

character with respect to fineness, or grade of excellence

and.

high grade; superiority; excellence

Often, and for some ironically, Quality Assurance or Testers are not actually the ones who define quality.  We can create tests, execute them and deliver our findings.  We can voice our concerns and/or approval based on the findings, but defining the quality may not actually be in our jurisdiction.  This is because, based on the definitions I shared earlier, Quality itself is defined by the end user.

A working piece of software that has no value to a consumer really has little to no actual value or quality.  Working doesn’t automatically bestow quality in software.

 Beyond the Testing – Quality Assured

This is why software testers, in order to grow, need to go beyond the test results.  Question exactly what you are testing; who will use it, how will they use it, how often?  Ask for defined, realistic workflows that the users will perform to better define the tests. See if you can even talk to some users as well and hear feedback directly from them.

When a bug or issue is found, ask yourself; will the user also find this bug? Will it prevent them from using the software? Will it affect their perception on whether the software has quality?

This will allow you to better prioritize your bugs to the developers and the project lead, leading to better bug advocacy from the tester.  Concentrating on fixing and testing issues that the user needs rather than get bogged down in the smaller, edge case issues.