CLASSIFICATION AND HANDLING OF DEFECTS
The defects which are also known as bugs or faults are anything that cause threading to the value, quality and aim of the software. It can be identified by the tester through the variance of expected results and actual results of execution of test cases. The defect-free software building is the impossible where the defects detected and solving the defects is the only way to achieve the defect free software. To achieve the goal the nature of the defects and the implementation methods of solving the defects should be known. Here the defects and handling of the defects in possible ways were discussed.
List of Defects in Software Testing:
The algorithms, login and data elements, module interface, the external software and hardware UI descriptions should be correctly designed. The incompatible or incorrectly designed modules lead to defects in the system.
An error in the sequences and logic is known as control flow error or command error. The reasons for such defects are missing command, wrong algorithm, incorrect data and code errors.
Boundary Value Defects:
In case the login page is logging in by giving the passport length to 16 characters in the place of 15 characters, then the defect is the boundary value defect.
Error Handling Defects:
The error that is raised while the users interacting with the software need to be handled in the correct flow. The flow should indicate the instruction in the popup message for the mandatory fields to alert the users for incorrect information.
Executing or running multiple tasks at the time. Complex debugging is possible in the multiple threading process. It may also lead to a system crash/failure due to the condition in deadlock.
The defects will be different by their nature of the risks. These defects are weaknesses allowing for a potential security attack.
The defects in the interactions of the software and the users. Some of the interfaces in the different kinds of forms are complicated interfaces, unclear interfaces and platform based interfaces.
- Priority of Defects:
- The impact of the bug of an application should be described.
- It is the order of priority which the developer will resolve the defects.
- The Priority can be changed based on the comparison with other defects.
- At the time of UAT, defects are fixed according to the priority.
Priority can be classified as follow as:
This generally occurs when the entire functionality of the task is fault and no more testing can do further for the result. Any defects that need immediate attention that affects the flow of the testing comes under this category. Critical severity also fall into the same category.
The defect that does not meet the exit criteria. Due to such defects the testing of the entire application has been stopped until the defects are solved. These defects are resolved once the critical issues are fixed. This kind of defect should be resolved before the release.
Defects occur when a particular feature cannot be used the way it should be because of defects in a program, environmental issue. These defects should be fixed once all the critical and serious bugs get fixed. These defects can also be fixed in the next release.
If few users of the feature encountered a defect such as minor UI issues, spelling mistakes, alignment issues and colour code mismatch are considered as low priority bugs. Sometimes these defects are opened to suggest enhancements in the existing design. This defect does not need any immediate actions as it can be resolved in future.
- Severity of Defects:
- It is related to the defect fixing urgency.
- The testers will set the level of severity.
- Once the Severity is fixed it won’t change with time.
- It is based on the functionality that the defects affect.
Severity can be classified as follow as:
When the whole functions feature / functionality missing from the project applications and completely crashes the system will be considered as Blocker and these severity defects are having the highest priority.
The implemented feature that does not meet the requirements, test cases and behaves differently than the normal flow. It does not cause any system kind of failure but not equal to the blocker but avoiding the unnecessary delay of fixing.
The defect will not cause a failure in execution of the applications which is not a major impact. Loss of data falls in the minor severity it also falls in major severity based on the classifications.
The valid defect that should be fixed even though there is no impact on the functionality.
Here are some combinations of Priority and Severity:
High Priority and Blocker Severity:
In the login page when the username and password is entered and click submit, instead of logging in the system crashes or else it throws the error message. In the Online site while adding the cart/payment options occurred in the critical times and in the final stage, this issue can impact on business at a great level.
Low Priority and Low Severity:
Spelling mistakes which are considered as minor in the pages. Colour of the button, contents, and hovering options mismatching. Minor alignment issues in the pages that do not affect the flow much.
High Priority and Low Severity:
Displaying the brand logo or the company logo in the company site does not impact the functionalities but it affects the value of the logo that plays the important role in the company website.
Low Priority and High Severity:
A defect found on the social networking site as the beta version of a new feature is released with not many active users using the facilities as today. Though this defect is having a functional defect, as it does not impact the customers directly.
Some of the other Defects are the following:
This is usually issued from the project specification without the knowledge in the documentation, but it also may be requested by the end users. It is considered a defect as it does not meet the existing requirements.
These defects arose due to the misunderstanding within the project team, client and non clearance of project documents. The falsely performed requirements come under wrong defects.
A feature that is not implemented according to the specifications which means the team has not noted the clients requirements properly.
It is difficult for the tester to identify whether it is a defect in deviation of the functionality or working of the software. If software is developed with no defects then there will be no need for testing but as long as the software exists in the business field there is possibility of defects found in the software due to the increasing complexity of the software.