Testers always encounter problematic behaviors of software when they are performing tests. Even though it is essential that all the bugs you come across must be reported, it is important to understand whether a bug is really a defect or a flaw.
It is very difficult to distinguish between a defect or a software defect or a flaw because it needs accuracy on the part of the tester to know the software functionalities. Nevertheless, software defect is a divergence from the requirements that lead to software malfunctioning. It doesn’t mean a bug in the code, in fact, it can be any function specified in the software requirement specification (SRS) document. However, it was not recognized, created or applied by the programmer. As a consequence, software behaves in an irregular manner.
Typical examples of software defects from a user’s perspective are as follows:
Situation 1: The software enables a user to make online payments via a debit card.
Defect: The required option for selecting a debit card to make payments is absent.
Situation 2: The software assists me to avoid grammatical errors.
Defect: The feature for noticing the grammatical mistakes is missing.
Following this, there are three unusual sorts of defects that confine a software to perform in conformance with its specifications. These defects can be managed using defect management software tool.
1. Latent Defect
A latent defect is a hidden flaw of a software not pointed out by the user unless you perform some operations. This flaw is recognized just when the software is expected to accomplish a specific task in the absence of routine situations or is exposed to uncommon circumstances. This defect generally accompanies a software in the production process and also passes to the pre-production testing.
Example of a Latent Defect
An app to print employee salary slips provides two different printer options i.e. laser printer, and dot matrix printer.
The app, however, by default always chooses laser printer options. As consequence, when the print command is introduced, printouts come out of the laser printer. It also tries to look for the Dot Matrix Printer (DMP), when the app cannot locate the laser printer. The app tries to print using DMP but generates an error message again and again.
Since the latent defect in the app was not tested for DMP and this sort of condition was not experienced while utilizing the laser printer, this flaw was never identified. This means while the testing, above-mentioned situation was not experienced.
2. Masked Defect
A masked defect is always present in the software. However, it has not caused any type of failure in the app performance primarily because it is masked by other defects. It is very difficult to identify masked defects because you cannot detect them unless the actual defect hiding it gets exposed or a particular operation is performed.
Example of a Masked Defect
Continuing the first example, where an app cannot be tested for DMP, two additional issues are masked i.e. DMP print and DMP print search.
The app fails to choose a laser printer because of which the DMP printing error was not noticed. As a consequence, the DMP print remained hidden.
3. Defect Cascading
Defect cascading refers to activating other defects in the app. If a defect is not noticed in the software testing, it invokes other defects. In other words, various defects crop up in the upcoming stages. Therefore, it is a master defect which introduces several defects linked to it onto the later stages of the app lifecycle.
Example of a Defect Cascading
An app has been organized to calculate employee’s monthly salary. The module required for calculating salaries has an unidentified defect. As a consequence, it miscalculates the salary. This prompts the database to convey wrong salary numbers which are further reflected in the annual salary calculations, tax calculations, and balance sheet.
Defect identification becomes challenging if this defect affects other functions in the app. You perhaps create various test cases to resolve issues, but it is time-taking and difficult. Being a tester, you perhaps opt for a subset of various test cases and perform them without worrying about dependence among test cases.
Conclusion
It is very ambiguous to identify, whether there is an error in the software functioning or it is a deviation in the software functionality. Therefore, it is important to understand various sorts of defects and apply test cases that are capable of defect identification. While defect cascading, latent and masked have the ability to become a leading cause of customer outage, you definitely avoid these by using defect management software tool.
