Defect Tracking

Defect Tracking
What is a defect?
As discussed earlier, defect is the variance from a desired product attribute (it can be a wrong, missing or extra data). It can be of two types – Defect from the product or a variance from customer/user expectations. It is a flaw in the software system and has no impact until it affects the user/customer and operational system.

What are the defect categories?
With the knowledge of testing so far gained, you can now be able to categorize the defects you have found. Defects can be categorized into different types basing on the core issues they address. Some defects address security or database issues while others may refer to functionality or UI issues.
Security Defects: Application security defects generally involve improper handling of data sent from the user to the application. These defects are the most severe and given highest priority for a fix.
Examples:
- Authentication: Accepting an invalid username/password
- Authorization: Accessibility to pages though permission not given
Data Quality/Database Defects: Deals with improper handling of data in the database.
Examples:
- Values not deleted/inserted into the database properly
- Improper/wrong/null values inserted in place of the actual values
Critical Functionality Defects: The occurrence of these bugs hampers the crucial functionality of the application.
Examples:
- Exceptions
Functionality Defects: These defects affect the functionality of the application.
Examples:
- All Javascript errors
- Buttons like Save, Delete, Cancel not performing their intended functions
- A missing functionality (or) a feature not functioning the way it is intended to
- Continuous execution of loops
User Interface Defects: As the name suggests, the bugs deal with problems related to UI are usually considered less severe.
Examples:
- Improper error/warning/UI messages
- Spelling mistakes
- Alignment problems

How is a defect reported?
Once the test cases are developed using the appropriate techniques, they are executed which is when the bugs occur. It is very important that these bugs be reported as soon as possible because, the earlier you report a bug, the more time remains in the schedule to get it fixed.
Simple example is that you report a wrong functionality documented in the Help file a few months before the product release, the chances that it will be fixed are very high. If you report the same bug few hours before the release, the odds are that it wont be fixed. The bug is still the same though you report it few months or few hours before the release, but what matters is the time.It is not just enough to find the bugs; these should also be reported/communicated clearly and efficiently, not to mention the number of people who will be reading the defect.
Defect tracking tools (also known as bug tracking tools, issue tracking tools or problem
trackers) greatly aid the testers in reporting and tracking the bugs found in software
applications. They provide a means of consolidating a key element of project information in one place. Project managers can then see which bugs have been fixed, which are
outstanding and how long it is taking to fix defects. Senior management can use reports to understand the state of the development process.

How descriptive should your bug/defect report be?
You should provide enough detail while reporting the bug keeping in mind the people who will use it – test lead, developer, project manager, other testers, new testers assigned etc. This means that the report you will write should be concise, straight and clear. Following are the details your report should contain:
- Bug Title
- Bug identifier (number, ID, etc.)
- The application name or identifier and version
- The function, module, feature, object, screen, etc. where the bug occurred
- Environment (OS, Browser and its version)
- Bug Type or Category/Severity/Priority
o Bug Category: Security, Database, Functionality (Critical/General), UI
o Bug Severity: Severity with which the bug affects the application – Very High, High,
Medium, Low, Very Low
o Bug Priority: Recommended priority to be given for a fix of this bug – P0, P1, P2, P3,
P4, P5 (P0-Highest, P5-Lowest)
- Bug status (Open, Pending, Fixed, Closed, Re-Open)
- Test case name/number/identifier
- Bug description
- Steps to Reproduce
- Actual Result
- Tester Comments

What does the tester do when the defect is fixed?
Once the reported defect is fixed, the tester needs to re-test to confirm the fix. This is usually done by executing the possible scenarios where the bug can occur. Once retesting is completed, the fix can be confirmed and the bug can be closed. This marks the end of the bug life cycle.