Software Defects Vs. Software Quality!

Software Defects Vs. Software Quality!

“If the software product has some defects, can it still be called a quality product?”

This is a question I was asked during a recent conversation with one of my blog readers (who is also a software tester). It appeared that the tester friend was asked this question in some testing interview and the interviewer had expected a simple YES/NO type answer! Unfortunately the tester, who was unsure about the answer, also expected a similar (YES/NO) answer from me for the above question. To me, this actually seems like a paradoxical question, which can be answered only after breaking it down further into few individual questions, which can throw more light on the context of the subject. But before I attempt to answer this question, let me assume few definitions of the keywords used in the question.

Software Product: A software product is typically a single application or suite of applications built by a software company to be used by *many* customers, businesses or consumers. The mass-market notion differs from custom software built for the use of a single customer by software development firms. – Wikipedia

Defects: A software defect (or "bug") is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most software defects arise from mistakes and errors made by people in either a program's source code or its design, and a few can also be caused by compilers producing incorrect code. – Wikipedia

Quality: Quality is value to some person, who matters. – Gerry M. Weinberg

Coming back to the original question, when someone asks, “if the software product has some defects, can it still be called a quality product”, I think a possible answer is: “I can’t tell you for sure unless you are ready to answer few of my questions first”!

If you are a software tester, I am almost sure that you are yet to see software, which does not have any defects in it (even after thorough testing). Even if the testers are not able to identify any significant amount of defects with further testing activity, still no tester with a stable brain on his shoulder would ever dare to state that “the software is defect-free after the testing effort”! In that sense, all software is with some defect (either known defects or yet-to-be-found defects). Since no software is without defect, what is the point in asking something like: "if the software product has some defect …"? What do you think?

I am not sure if the interviewer actually wanted to ask: “if the software product has some *known* defects *after it’s release*, can it still be called a quality product?”

This sounds to me like a more meaningful and tractable question which can be attempted for answering! As a software tester, I understand that there can be situations when a product is known to have some unfixed defects and yet the management can decide to release the product. This can particularly happen when,

a) The known defects are of low severity and are less devastating. Even if the end-user encounters such defects, it is speculated that the defects would not cause much trouble/nuisance to the end-user.
b) These are corner case defects and the chance of the end-user being hit by such defects is less.
c) The stakeholders of the project don’t feel that these defects are of much importance!

Whatever might be the reason behind the decision to release the product with those known defects, I am not sure if we can surely tell that the shipped product is of high quality or not, simply on the basis of the defects shipped with the product! Echoing some experts in software testing, quality of software is much more than presence or absence of defects. Imagine a software product, which is shipped with a belief that it does not have any known defects and is quite stable. But wait! What if the end-user does not like it, as it is difficult to learn and operate? What if, it is difficult to train others how to use the software? In a single sentence, what if the product fails severely from usability aspect? Think of a video game, which is very robust (does not crash easily) and lacks any visible defect, and yet the persons who play this game don’t find it interesting enough! Can we still call it a quality software/video game? I guess not!

Coming back to our original question, even though a software product has defects, it could still be called a quality product. At the same time, even though a software product has lesser known-defects, it might not be of good quality! Quality of software is multi-dimensional and can't be decided by the presence or absence of defects alone! Hence, it might be little tricky to answer the above question, without being clear on the understanding of quality by the particular organization. As a tester, do you think you can answer the above question? I am eager to hear your views on the subject.