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 tactable 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.

Happy Testing…
Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.

4 Comments:

  1. I would reply him something like this ...

    "The answer depends upon
    1) who is asking this question and what is his stake in the product's success or failure
    2) what is this person's definition of Quality? How will he/she distinguishes a quality product from something that is a not so quality product?
    3) what is his definition of defect or bug.

    If you get the answer to these questions (you need not have to see and use the software he is talking about), you will be able to say whether the product with bugs is a quality product.

    BTW do you think MS word software is a quality software?

    Calling a software with bugs as a low quality software is a "sweeping generalization" ...

    You might want to check out my recent blog on quality ....

    http://shrinik.blogspot.com/2008/01/percipient-subject-and-softwar-quality.html

    ReplyDelete
  2. Coverity Prevent, a static source code analysis tool can fix critical defects like memory leak, array overrun, uninitialized data, dangling pointer etc.
    Defects in multithreaded application development like Thread block, Dead lock and Race conditions can also be solved using Coverity Prevent.
    Coverity has customers like Symbian, RIM (Blackberry), Juniper networks, Cisco, Texas instruments and is also used by the Department of Homeland security to scan lots of open source projects. You can get more info at http://www.Coverity.com.

    ReplyDelete
  3. Actually It depends upon the Requirement fulfillment of the client.If a client is satisfied with the product even if it has a bug then still it is a "Quality Product".I would like to Quote - WindowsXP(Undoubtedly has millions of Satisfied Customers despite of the fact that it has hundreds of major bugs - But there is a case that a Satisfied customer has never encountered any of those bugs).
    Hence Quality of a Product is always a relative term with the "Customer's Satisfaction" level.

    ReplyDelete
  4. they are confusing terms, how ever a world of difference among them

    ReplyDelete

NOTE: Comments posted on Software Testing Tricks are moderated and will be approved only if they are on-topic. Please avoid comments with spammy URLs. Having trouble leaving comments? Contact Me!