The defect is a variance between expected results and actual results of execution of test case on the system. The number of defects (all major ones and minor ones) found in the application is directly proportional to the quality of the application. Defect in software testing can be find using automation tools also.
Table of Contents
Defect Management Tools
Defect management tools are the application software or web applications in which we record the defect details and assign it to the developers for fixing the defects. Popularly used Defect management tools are Quality Center, JIRA, Bugzilla, Scarab etc.
Severity:
Severity is the amount of impact what a defect can make on the application.
Ex: Mails are not sent from a Mail Server application. Here the Its a very “Severe” Defect since the main functionality of the mail server is to send mails.
Priority:
Priority is given by developers or managers for fixing a defect based on their severity.
Ex: Mails are not sent from a Mail Server application. Here the Defect needs to Highly “prioritized” and fixed.
Categories of Defects
- Functional
- Non Functional
Functional Defects
- Wrong : The software does something that the product specifications says it shouldn’t do.
- Missing : The software doesn’t do something that the product specification says it should do.
- Extra : The software does something that the product specification doesn’t mention.
Non Functional Defects
The defects which is difficult to understand, hard to use, slow etc.
Causes of Defects
- User gives wrong or incomplete requirements.
- Analyst interprets requirements incorrectly.
- Requirements are not recorded correctly.
- Incorrect design.
- Error in coding.
- Data entry error.
- Mistake in error correction.
- Defect classification:
Defect classification is nothing but the process of assigning priorities to the defects found while testing based on their impacts.
Usually there are several Classification methods used in difference companies.
Below given classification will help to understand the classification:
P5: – Blocker Very high priority defect which is a “show stopper”. Application cannot be tester further until this defect is fixed. Application also cannot be released once this issue is fixed.
Ex: not able to send any mail from the mail server application.
P4 – Critical: Not a showstopper but still affects the important area of the application.
A possible work around may exist which may not be helpful all the time.
Ex: Mails are reaching only the people marked in “TO” and “CC”. But not working for “BCC”
Usually when the release very urgent , Project managers might communicate to the end users saying there is an existing issue, and this will be solved in the earlier patch release.
We can still send mails through Cc but this is an importanct defect.
P3 – Important: Defects found in the less priority areas of the software. The product can still be released into production
even without fixing these defects. But would require a fix in the later cycles.
P2 – minor :Very Cosmetic issues like extra space in the page, or spelling mistakes. Good to have fixes with respect to the standard quality of the application
- Good Defect logging practice:
Defect logging is an important task as Developers might come back to testers the in case of a Non Clear description which would result in a in delay for bug fixes. A good Defect logged makes the developer fix the bug at the earliest time without much debugging.
Ex:
Lets say there is a defect in the application where Customer Name is not displayed in the page. The same customer name is supposed be displayed in 5 other places of the application
- Bad Defect Description:
Customer Name is not visible.
- Good Defect Description:
Customer Name is not visible in the Home page after we login to the application. Customer name is visible in other 4 pages of the application.
Now here we can observe that a Good defect description makes a developer look for the code only in the home page and fix the defect. In the case of a Bad description, developer will need check in how many pages the customer name is not visible which results in the delay.
Also If the testing team is able to get any sort of system logs, it would be much more helpful for the development as the root of the problem will already be visible in the log entries.
Its always a better practice to the log the defect with a very brief descriptive explanation, Related screenshot and the log entries.
- What does a Software Tester do once defect is fixed:
Lets take the above given example:
Lets assume that the defect is fixed and the customer name is visible in the home page. The job of a tester does not stop there but he/she will also check other 4 places of the application where its supposed be displayed while retesting. At the end the Tester should make sure the customer name is present in all the five places of the application. This is called tracking defect to closure.
Also check :
- Now Get Paid to Find Software Bugs Online
- What is Defect & How to Write Defect Report
- Defect Report Templates
