As a tester, you tend to become used to hearing people who worked on a product proudly declare that their application works flawlessly and that there are no more defects present.

As a matter of fact, this belief is so frequently used that it is part of the 7 core principles of testing defined by the ISTQB, which is aptly named the absence-of-errors fallacy.

Basis of the fallacy

To even begin to entertain the idea that a software product is completely devoid of defects, one must automatically assume that the person making the statement has complete knowledge of the software, its behavior and all possible outcomes when using it, in a way that he can perfectly predict how it would behave under any possible circumstance. Doesn’t sound all that plausible anymore, right?

The same principle also states that a large number of defects fixed does not ensure the success of a system. In the same idea, a low number of defects found does not necessarily mean that the application is free of any other issues.

It’s important to categorize defects into two separate classes: objective and subjective.

An objective defect would be a behavior that contradicts what the requirements state: I’m trying to log out of the portal, but instead of being returned to the landing page, nothing happens and I’m still logged in.Or maybe I want to update my user’s address, but after clicking “Save” I now appear as being named after my home’s street address.

On the other hand, a subjective defect would be a behavior that hinders the accessibility or the performance of the application. I’m trying to log in but the page has been loading for over two minutes; I want to create a user account but there are so many steps that I’ve just given up.

While objective defects can be identified and solved to some extent, owing to the requirements being a clear request of what a behavior should be, how can we expect to have zero defects when subjectivity exists?

After all, a process that’s hindering and unpleasant to me might not be anywhere near as bad for another user.

Understanding why the fallacy is important

We now know that claiming a product to be entirely without defects is not feasible, but how does it affect us knowing that this is the case?

Outside of how damaging it would be to legally claim that your deliverable product has no defects, it’s good to bear in mind that defects will always exist.

You may not be able to ensure the impossible task of a product with zero bugs, but what you can ensure is a quality product, using proven and practical techniques of testing.

For testers, claims of “my product is perfect and has no issues” should be treated a challenge.

Not to prove if the person stating it is wrong, but to prove how badly they’re wrong.

‍