Defect Management

DEFINITION:

 

A Software Defect / Bug is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results.

  • A program that contains a large number of bugs is said to be buggy.
  • Reports detailing bugs in software are known as bug reports. (See Defect Report)
  • Applications for tracking bugs are known as bug tracking tools.
  • The process of finding the cause of bugs is known as debugging.
  • The process of intentionally injecting bugs in a software program, to estimate test coverage by monitoring the detection of those bugs, is known as bebugging.

Defect Management

Defect management is crucial to closing the loop between requirements, implementation and verification and validation. Traditional defect tracking management, implemented in a standalone fashion, can no longer address the complexity and pace of change in modern software development. Defect management processes must be tightly interlinked with all of the other software development processes. The defect management process contains the following elements:

Defect Discovery – Identification and reporting of potential defects. The defect tracking software must be simple enough so that people will use it, but ensure that the minimum necessary information is captured. The information captured here should be enough to reproduce the defect and allow development to determine root cause and impact.

Defect Analysis & Prioritization – The development team determines if the defect report corresponds to an actual defect, if the defect has already been reported, and what the impact and priority of the defect is. Prioritization and scheduling of the defect resolution is often part of the overall change management process for the software development organization. 

Defect Resolution – Here the development team determines the root cause, implements the changes needed to fix the defect, and documents the details of the resolution in the defect management software, including suggestions on how to verify the defect is fixed. In organizations using Software Product Lines approaches, or other shared component approaches, defect resolution may need to be coordinated across multiple branches of development.

Defect Verification – The build containing the resolution to the defect is identified, and testing of the build is performed to ensure the defect truly has been resolved, and that the resolution has not introduced side effects or regressions. Once all affected branches of development have been verified as resolved, the defect can be closed.

Defect Communication – This encompasses automatic generation of defect metrics for management reporting and process improvement purposes, as well as visibility into the presence and status of defects across all disciplines of the software development team.

As a unified development solution Integrity supports all other disciplines in the application lifecycle - not just defect management. Traditional defect management software cannot achieve the seamless links among all activities and assets that is needed in today's fast-paced and complex development environments. Integrity improves product quality and customer satisfaction by facilitating defect tracking across product variants. Combining these linkages with unprecedented process flexibility makes Integrity the best choice for addressing challenges such as:

  • Discovery and Notification

  • Defect Resolution across Multiple Lines of Development

  • Automated Defect Verification

Defect Management

After uncovering a defect (bug), testers generate a formal defect report. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.

 

DEFECT REPORT TEMPLATE

In most companies, a defect reporting tool is used and the elements of a report can vary. However, in general, a defect report can consist of the following elements.

ID

Unique identifier given to the defect. (Usually Automated)

Project

Project name.

Product

Product name.

Release Version

Release version of the product. (e.g. 1.2.3)

Module

Specific module of the product where the defect was detected.

Detected Build Version

Build version of the product where the defect was detected (e.g. 1.2.3.5)

Summary

Summary of the defect. Keep this clear and concise.

Description

Detailed description of the defect. Describe as much as possible but without repeating anything or using complex words. Keep it simple but comprehensive.

Steps to Replicate

Step by step description of the way to reproduce the defect. Number the steps.

Actual Result

The actual result you received when you followed the steps.

Expected Results

The expected results.

Attachments

Attach any additional information like screenshots and logs.

Remarks

Any additional comments on the defect.

Defect Severity

Defect Severity or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software.

ISTQB Definition
  • severity: The degree of impact that a defect has on the development or operation of a component or system.

DEFECT SEVERITY CLASSIFICATION

The actual terminologies, and their meaning, can vary depending on people, projects, organizations, or defect tracking tools, but the following is a normally accepted classification.

  • Critical: The defect affects critical functionality or critical data. It does not have a workaround. Example: Unsuccessful installation, complete failure of a feature.
  • Major: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
  • Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
  • Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.

Defect Priority

Defect Priority (Bug Priority) indicates the importance or urgency of fixing a defect. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.

Priority can be categorized into the following levels:

  • Urgent: Must be fixed in the next build.
  • High: Must be fixed in any of the upcoming builds but should be included in the release.
  • Medium: May be fixed after the release / in the next release.
  • Low: May or may not be fixed at all.

Priority is also denoted as P1 for Urgent, P2 for High and so on.

NOTE: Priority is quite a subjective decision; do not take the categorizations above as authoritative. However, at a high level, priority is determined by considering the following:

  • Business need for fixing the defect
  • Severity/Impact
  • Probability/Visibility
  • Available Resources (Developers to fix and Testers to verify the fixes)
  • Available Time (Time for fixing, verifying the fixes and performing regression tests after the verification of the fixes)

Reported By

The name of the person who reported the defect.

Assigned To

The name of the person that is assigned to analyze/fix the defect.

Status

The status of the defect. (See Defect Life Cycle)

Fixed Build Version

Build version of the product where the defect was fixed (e.g. 1.2.3.9)

 

REPORTING DEFECTS EFFECTIVELY

It is essential that you report defects effectively so that time and effort is not unnecessarily wasted in trying to understand and reproduce the defect. Here are some guidelines:

  • Be specific:

    • Specify the exact action: Do not say something like ‘Select ButtonB’. Do you mean ‘Click ButtonB’ or ‘Press ALT+B’ or ‘Focus on ButtonB and click ENTER’? Of course, if the defect can be arrived at by using all the three ways, it’s okay to use a generic term as ‘Select’ but bear in mind that you might just get the fix for the ‘Click ButtonB’ scenario. [Note: This might be a highly unlikely example but it is hoped that the message is clear.]

    • In case of multiple paths, mention the exact path you followed: Do not say something like “If you do ‘A and X’ or ‘B and Y’ or ‘C and Z’, you get D.” Understanding all the paths at once will be difficult. Instead, say “Do ‘A and X’ and you get D.” You can, of course, mention elsewhere in the report that “D can also be got if you do ‘B and Y’ or ‘C and Z’.”

    • Do not use vague pronouns: Do not say something like “In ApplicationA, open X, Y, and Z, and then close it.” What does the ‘it’ stand for? ‘Z’ or, ‘Y’, or ‘X’ or ‘ApplicationA’?”

  • Be detailed:

    • Provide more information (not less). In other words, do not be lazy. Developers may or may not use all the information you provide but they sure do not want to beg you for any information you have missed.

  • Be objective:

    • Do not make subjective statements like “This is a lousy application” or “You fixed it real bad.”

    • Stick to the facts and avoid the emotions.

  • Reproduce the defect:

    • Do not be impatient and file a defect report as soon as you uncover a defect. Replicate it at least once more to be sure. (If you cannot replicate it again, try recalling the exact test condition and keep trying. However, if you cannot replicate it again after many trials, finally submit the report for further investigation, stating that you are unable to reproduce the defect anymore and providing any evidence of the defect if you had gathered. )

  • Review the report:

    • Do not hit ‘Submit’ as soon as you write the report. Review it at least once. Remove any typos.

 

Defect Life Cycle - Workflow:

Defect Life Cycle in Software Testing

Defect Life Cycle States:

  • New - Potential defect that is raised and yet to be validated.

  • Assigned - Assigned against a development team to address it but not yet resolved.

  • Active - The Defect is being addressed by the developer and investigation is under progress. At this stage there are two possible outcomes; viz - Deferred or Rejected.

  • Test - The Defect is fixed and ready for testing.

  • Verified - The Defect that is retested and the test has been verified by QA.

  • Closed - The final state of the defect that can be closed after the QA retesting or can be closed if the defect is duplicate or considered as NOT a defect.

  • Reopened - When the defect is NOT fixed, QA reopens/reactivates the defect.

  • Deferred - When a defect cannot be addressed in that particular cycle it is deferred to future release.

  • Rejected - A defect can be rejected for any of the 3 reasons; viz - duplicate defect, NOT a Defect, Non Reproducible.

Print Print | Sitemap
© 2016 Automation Learn. All rights reserved.