A defect in software is an unexpected condition, features or bugs in the software which may not be a user requirement or may lead to misfunctioning or malfunctioning of the software itself.
A Defect can occur at any time in the running of the software or may be induced in the development phase of the software itself.
A defect may be external or internal. External defects are easy to sort out and are not that dangerous. Whereas the internal or the hidden defects can crash the entire software or force it to compromise.
There may be different reasons for a defect in the software. Such as- mistake of programmers, bad programming style, mismanagement in the program files, easily breakable algorithms, etc. The reason behind a defect is infinite. In this article, we shall see the types of defects, reasons for defects, etc.
Defect Life Cycle
It classifies whether the defect is ignorable or severe. Whether it may create drastic damage to the software and its operations, or whether it can crash the software to lead to data compromise.
This is a parameter which determines how much positive and negative impacts, the defect may have on the software. This parameter directly reflects what are the major consequences the software may face due to the presence of the defect in the software.
Now the severity of the defect may of different degree. And thus can be classified as follows-Critical, Major, Minor, and Trivial.
Critical Defects are those defects, which affects the critical functionalities of the software. The induction or occurrence of these kinds of defects may cause the software functionality to fail or even the security may break internally in the software.
This kind of defect may be very hard no defect and these defects are present in those part of source codes which are responsible for security, installation, process initiation, algorithm selection, etc
To defect critical defects are generally found by professionals who have a good knowledge of the coding as well as the hardware.
This defect may impact the software and force it to reach a state, which can be either a deadlock or may not be a workaround (That is cannot be solved without stopping the software.)
Major defects are the defects which can impact the software's major functionality such as working of its components, interface, security protocols, etc. But this is not that severe compared to critical defect. This may have a workaround.
Major defects also may lead to a total software failure, but there are possibilities that the software can roll back into its normal state or even choose a basis path or an alternate path to execute the tasks normally.
A Software may not get executed when trying to follow a direct path and may fail in the first step of process creation, but the software can choose different paths to somehow initiate the process of a module and shift the program control to other modules.
Some of the major defects in software may be as follows :
The list will go on ! So, we shall not keep pointing out more.
Minor defects are the defects which are not that, severe nither compared to the critical defects nor the major defects. This kind of defects are small defects and can be ignorable sometimes, and can be sorted later on.
Minor defects though simple and easy to sort must not be taken that lightly, as the good fact is only that, it will not affect the system severely or may not affect the operations but in long term, if the defect is sustained, it may act as a critical defect, it overlooked.
Some examples of minor defects are listed below:
Trivial Defects are those defects which are so minor that can be ignored. This defect does not affect the functionality of the software and so can be ignored. The defect will not have any change or modifications in data or program and so, the defect does not require any action.
Examples of Trivial Defects are: Invalid Form Validation, increased response time, etc.
Probability of defect means the frequency of encountering the defect by the user. It may be noted that all the defects will not come across in the normal functioning of the software again and again. The user is less likely to face the defect which is hidden.
For example, the function to clear the cache may not clear the cache, when the clear button will be hit. But the user will seldom come across this defect, as the user may wish to clear the cache wither after many days or in the very need to clearing it.
Now, the probability that a defect will be encountered by the user while using the software can be - high, medium and low.
Before, proceeding, it should be mentioned that there are different users for the software. Such as the administrator, the clients, naive users, etc. All the different users use the software from different perspectives.
The technical in-charge will use functionalities such as updating_database, shell_management, Protocol_checking, etc.
The administrator will use functionalities such as content_management, account_management, etc.
The client will use the functionalities such as account creation, content review, etc.
The naive user will dive into the interface of the software to understand how it works and what are the different things to learn for using the software.
Defect priority means how fast and how sooner the defect should be fixed. Priority is the parameter which reflects how important is the defect and how effectively the defect should be fixed.
Based on defect priority, the defects can be categorized. They are:
When we talk about dimensions, there are different attributes which affect the quality of the software, in terms of its usability and security. There are more than thousands of dimensions of a softwares which decides the quality, we shall discuss the most important ones.
Below we mention the attributes and define them:
There are different elements which contribute to the quality of the software.
This is the module in which the defect of the software is found. When a defect occurs in software it occurs in part of the software and not in the entire software. The modules are categorized and when the defect is encountered, the module can be easily referred, by its category.
The defect can be addressed as-> defect in Component1 of module A.
This is a category in which the defect is identified or detected. This can be any of the phases of the software testing cycle. The defect can be identified in the Unit Testing, Integration Testing, System Testing, Acceptance Testing, etc.
This indicates the phase in which the bug or the defects is injected into the software. It may be noted that the defect is always injected in a phase earlier to the phase in which the defect is identified.
The phases in which the defect gets injected are: