Latent Defect: The Hide ‘n’ Seek Defect in Software Testing

Latent Defect The Hide 'n' Seek Defect in Software Testing

Latent Defect is a popular term in the dictionary of software testing. This is a defect that is not known to the customer unless he faces an unforeseen situation but at the same time the developer or the seller is aware of the defect. This defect comes to existence because the truthful set of conditions was never met, it is present in the system for a long time, probably during the production process, goes through the pre-production testing and extended use. The bug may exist in the system for one or more versions of the software and may be identified after its release. One of the reasons why Latent Defect exists is because exact set of conditions haven’t been met. This defect seems to be a sly one that does not cause any harm at the moment but waits to show its true colours.

Latent defects can be identified effectively with inspections. Regarding the true volume of latent defects shipped with a product to users, in most cases this can never really be determined. We do not yet have the ability to decisively determine the real number of defects shipped with a product. We can project total defects based on other characteristics in the process or we can assume zero defects based on other process data and patterns, but we cannot prove it. For example, we can analyze error depletion curves prior to delivery to make a prediction of latent defects after delivery.

Let’s imagine that an application is able to print a document either by laser printer or by dot matrix printer. To reach this, the application first searches for the laser printer. In this case if it finds a laser printer (used by default) it uses this one and prints. In case if it does not find a laser printer, the application searches for dot matrix printer. And if the application finds a dot matrix printer, it  gives an error message. This unleashes a latent defect.

Therefore this application will never search for the dot matrix printer. And the application never got tested for the dot matrix printer. That means the accurate conditions were never met for the dot matrix printer. This is what we call a latent software bug.

It is very difficult to identify the Latent Bug by using conventional testing techniques, it can be identified by doing code review or by usability testing which foresees the forth coming problems.

What are the signs of Latent defects?

Be smart and apply the easiest way – process the set of triggering events against older versions of the software and find that if the bug has been hanging around from a long time since the past. Actually, you don’t get to call a bug a latent defect if you haven’t paid enough attention to testing the system properly. That’s just ignorance, no matter how long the bug has been sitting around!

Latent defects are hence those that even remain after the production of the product. They certainly pass the initial tests both stages of pre-production testing and extended use. They are there, hiding and waiting for us to seek them. Though, now software testing processes and higher techniques have been created to wipe out such loopholes/defects yet some unforeseen defects remain covert. So, as software testers, you should understand and apply appropriate test cases to pinpoint the defects.


Get A Free Quote

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.