Defect Tracking

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.

Categories of Defect: 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.

1.     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

2.     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

3.     Critical Functionality Defects: The occurrence of these bugs hampers the crucial functionality of the application.

Examples:

·         Exceptions

       4.     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

5.     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 won’t 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

Bug Category: Security, Database, Functionality (Critical/General), UI

Bug Severity: Severity with which the bug affects the application – Very High, High, Medium, Low, and Very Low

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.