Thursday September 8, 2016
As a tester, you would be confronted with problematic behaviors of software while performing testing. While it is necessary that every bug (also referred as errors, issues or problems) you encounter needs to be reported, it is necessary to identify whether a bug is really a flaw or a defect.
Well, it is very difficult to differentiate between a software flaw and a defect since it requires precision on the part of tester to understand the software functionalities. However, in simple terms, software defect is a deviation from the requirement that causes malfunctioning of a software. It does not necessarily mean a bug in the code. It can be any function that was specified in the Software Requirement Specifications (SRS) document but was not recognized, developed or implemented by the programmer. As a result, the software behaves in an anomalous manner.
From a user’s perspective, typical examples of software defects are as follows:
Scenario 1: The software will allow a user to make online payments using a debit card.
Defect: The option of selecting a debit card for making payments is missing.
Scenario 2: The software will help me in avoiding spelling mistakes.
Defect: The feature for detecting the spelling error is missing.
In line with this discussion, here are 3 unusual types of defects that restrict a software to perform in conformance with its specifications. These are as follows:
A Latent defect is a hidden flaw in a software which is not identified by the user (although the developer/owner is aware of it) until a set of operations is not performed. This flaw is identified only when the software is expected to perform a particular task in the absence of regular scenarios or is exposed to unusual circumstances This defect usually accompanies a software during the production process, and also passes to the pre-production testing.
Example of a Latent Defect
An application to print salary slips of the employees which provide two different printer options to print in the dropdown:
However, the application by default selects the Laser printer always. As a result, whenever the print command is initiated, printouts come out of the Laser printer. When the application is unable to locate the laser printer, it tries to find the Dot Matrix Printer (DMP). The application attempts to print using DMP but repeatedly gives an error message.
Since the latent defect in the application was never tested for DMP and since this condition was never experienced while using the laser printer, this flaw remained hidden. This implies that while testing, the aforementioned scenario was never experienced.
A Masked Defect is a defect already existing in the software, however, it hasn’t caused any failure in the application execution mainly because it is covered or masked by another defect. Masked Defects often are difficult to identify since they do not get detected until the actual defect hiding it gets uncovered or a specific operation is performed.
Example of a Masked Defect
As per the first instance where an application was not tested for DMP, further two issues are masked.
The application always failed to select Laser printer due to which the DMP printing error was never detected. As a result, the DMP print remained hidden.
In software testing, Defect Cascading means triggering of other defects in the application. When a defect is not identified or goes unnoticed while testing, it invokes other defects. As a result, multiple defects crop up in the later stages. In other words, it is a master defect which introduces many defects linked to it onto further stages of the application lifecycle.
Example of a Defect Cascading
An application has been deployed to calculate monthly salary of the employees. The module responsible for calculating salaries is having an unidentified defect. As a result, it wrongly calculates the salary. This prompts the database to transmit incorrect salary numbers which are further reflected in the balance sheet, tax calculations, and annual salary calculations.
If defects cascading continues to affect other functions in the application, identifying the affected function becomes challenging. You may make different test cases to solve this issue, but it is difficult and time-consuming. As a tester, you may select a subset of different test cases and execute them without bothering about interdependencies among test cases.
Being a tester it is difficult to know whether it is an error in the working of the software or it is a deviation of functionality in the software. Hence, it is imperative to understand different types of defects and implement test cases capable of identifying these defects. While Latent, Masked and Defect cascading possess the ability to become a dominant cause of customer outage, you can definitely get over these by utilizing standardized processes and software testing tools, TestingWhiz being one of them.
If you don’t want to miss catching the above defects, test your application with TestingWhiz. Download now