DevOps Zone is brought to you in partnership with:

Mr. Mahal has worked his way through all aspects of software development. He started as a software engineer and learned how to design and architect software systems in different industries. He has been a director of engineering, product management, and professional services; mid-career he worked for a company dedicated to training engineers in collecting requirements and understanding OO and conducted research into why software projects fail; and before starting Accelerated Development he rescued a technology startup in Vancouver as their COO. Accelerated Development is dedicated to the production of high quality software through implementing light weight engineering practices for all size organizations up to Fortune 500. Dalip is a DZone MVB and is not an employee of DZone and has posted 37 posts at DZone. You can read more from them at their website. View Full User Profile

Don't Manage Enhancements in the Bug Tracker

11.11.2013
| 2937 views |
  • submit to reddit

As development progresses we inevitably run into functionality gaps that are either deemed as enhancements

These issues often get captured by QA in the bug tracker and assigned to a developer that will be unable to resolve the issue.

Assigning issues to the wrong people will cause the defect to bounce around like a hot potato and waste everyone's time.

Enhancements are a requirements defect that can not be resolved by either QA or the developer.

The life cycle of a defect and the life-cycle of a enhancement are two entirely different things.  A defect is a difference between a stated requirement and the code. If there is no documentation then there is no code defect (see It's not a bug, it's ... )

Most enhancements will eventually be coded by some developer; they just should not be managed from the bug tracker. They need to go through the requirements process to determine whether or not the change will be made.  Even when changes are made they can be very different from what QA or the developer expects.

Defect Life-cycle

The defect life-cycle is well known:

  • Defect is identified as a departure from the requirements
  • Defect is assigned to a developer
  • Defect is corrected
  • Correct is verified
    • If not corrected re-open and re-assign to developer
  • The defect is closed


This is the correct way to manage a defect.

This is the incorrect way to manage enhancements. When QA discovers functionality not covered by the requirements then we have an issue; however, it is unlikely that it will be resolved by a developer.

Therefore assigning enhancements to developers is simply going to waste time because neither QA nor developer should be deciding requirements.

Non-Code Defect Life-cycle

There are defects that are not coding defects, this includes:

  1. Insufficient requirements
  2. Correct requirements but incorrect test plans

Enhancements are really requirement defects. Enhancements should be logged as such in the bug tracker and assigned to the person in charge of requirements (business analyst or product manager).  Those individuals should be responsible to track down how these issues should be handled. 

If the requirements are correct and the test plans are defective then it should be logged as a test defect. This is tricky because QA often controls the bug tracker and may not  log errors that they commit.  This is typically reported in QA with a functions as designed status.

At a minimum, the implementation of requirements and test defects in the bug tracker can do several positive things for you:

  1. It removes the responsibility to find a solution from development.
  2. It makes it clear how many defects are in the requirements or test plans.
  3. It reduces stress; no developer wants to be blamed for an issue that is not his.
  4. Many enhancements call for updated project plans and pushing back the deadline.

Put Responsibility Where it Belongs

The creation of requirements and test defects in the bug tracker goes a long way to cleaning up the bug tracker.  In fact, requirements and test defects represent about 1 out of 4 of defects in most systems.

The percentages break down as follows:

  • Requirements defects: 9.58%
  • Testing defects: 15.42%

The creation of requirement and test defects in the bug-tracker alleviate pressure on the engineering department and redirect it  to either the product manager or QA. Eventually enough data will accumulate in the bug-tracker to getmanagement's attention.

At a minimum, these defect categories should help reduce the amount of fire-fighting at the end of a project..


Published at DZone with permission of Dalip Mahal, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)