SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Junior Member
    Join Date
    Oct 2003
    Location
    Cali
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    BUG/Defect Management Workflow

    We are currently re-engineering our workflows in our Development, QA and Help Desk team and are trying to determine a Best Practice Workflow for managing BUGS. The problem is that no one wants to take ownership of a BUG. Is this common in other organizations?

    Help Desk doesn't want it because they do not have the power or skill set to resolve a bug.

    Developers do not want ownership because they are busy working on projects, and there is much work in investigating a bug.

    QA doesn't take ownership because they feel Help Desk should do the majority of testing and investigation before assigning it to Development.

    Can someone respond and provide some feedback to the following questions?

    1. Which department should take ownership of a Bug? And what do most companies do?

    2. Should Help Desk be performing testing to QUALIFY a bug?

    3. Does anyone have a sample bug workflow?

  2. #2
    Senior Member
    Join Date
    Mar 2003
    Location
    Elkhart, IN, USA
    Posts
    264
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    The September 2003 issue of CrossTalk is devoted entirely to Defect Management. You can find it on-line at Sept 2003 CrossTalk . There is specifically an article about the Bug lifecycle. The author provides a flowchart of what they built for their shop.

    CrossTalk is a free software magazine distributed by the US Air Force. I would highly recommend it to anyone in the software world.

    Michael
    Michael L. Hovan
    mrschovan@verizon.net

  3. #3
    Junior Member
    Join Date
    Oct 2003
    Location
    Cali
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    Hi Michael,

    Thanks for your reply, the link was very useful, but it doesn't address my area of focus. Do you know if in your company or in other organizations that you have been involved with if Bug Investigation tasks and Bug ownership fall in the realm of Help Desk departments or QA departments.
    Your feedback on this would be very helpful.

  4. #4
    Junior Member
    Join Date
    Aug 2001
    Location
    Cleveland, OH
    Posts
    26
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    We went through a similar problem about two years ago and then went through a lot of trial and error issues getting a good process in place. One main question to look at is out of your current process what is working and what is not working? Is the only issue of someone taking ownership? When we redesigned our process we started from scratch and asked ourselves the following questions:

    - Is there a different starting point for internal environment issues compared to production defects?
    For example - for production defects, our help desk takes all calls/e-mails for internal defects, our QA team takes all calls/e-mails

    - how are defects identified/logged and by whom?
    For example - we have a separate tracking device for production defects compared to internal defects which determines which route the defect will take

    - do you have any SLA's in place? This greatly impacted our workflow and the turnaround time for each team

    After much work and refinement we learned that the development team was the bottleneck so we added a "sub-development" team that works only on production issues. They are given smaller projects when things are quiet but their main focus is just production issues.

    Hopefully some of these evaluation points will take you back to a clean drawing board and then you can add in the processes that were working and see what's missing.

  5. #5
    Super Member
    Join Date
    Oct 2001
    Location
    Bucharest, ROMANIA
    Posts
    1,366
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    We had this problem,too.
    The problem is not very simple, because if Help Desk is involved, it is NOT only a softaware development problem. It address the problems which arise AFTER the releasing into production.

    I'll try to expose our environment and how I proposed to manage it:

    -I work in the IT department of a TELCO
    -our development team is responsible to develop in-house solutions other departments or other new services .
    -during development we have a "normal" defect tracking process, with regular actors: project management, development, testing, customer (a business department), using Rational ClearQuest.
    -after releasing the application into production, it is operated by Operations. Any problem it is addressed ONLY to Help Desk, which is considered 1st level support.

    - Help Desk main duty is to classify the issue they receive ( through other application: Remedy), and if it is theirs competency, to solve it. So, they try to get as many details are necessary to understand the problem, determine if it's a computer configuration/hardware/network problem. If not they would assign the issue to the Application Support team, which is level 2 support. They check to see if it is a known problem, determine the possible cause, fix the problem if it's related to theirs competencies ( application server/database problem, wrong utilization,...
    If it's a new problem they Open a bug in ClearQuest and assign to Development team to address it.

    If you have only one tool it could be easier, but also could make your life more difficult. The problem you should consider is that Help Desk will NOT receive only bugs ( from my experience, less than 10% are bugs), but a lot of opperational issues. Even where it is a bug, Help Desk will receive several errors caused by the bug, from different people, with different descriptions. One condition would be that the support teams to have access to the open issue for every specific application.

    Which is QA's main role? In my approach QA should handle all the bugs wich passed level 2 support unsolved, and the bugs are passed to development.

    I'm sure that there are many different approaches, but that approach DID work for the project I was involved in (as QA/Testing lead for that project)
    Don't worry, be Happy!

  6. #6
    Senior Member
    Join Date
    Mar 2003
    Location
    Elkhart, IN, USA
    Posts
    264
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    This is a good question and there are some very thought provoking concepts showing up. Thank you for asking and persisting with it.

    I supposed that the best answer is "it depends". Each shop and industry is different. Attempting to apply cookie cutter solutions is counter productive. That is what strikes me about this discussion thread - no "one size fits all" solutions are showing. Very refreshing.

    The best experience that I have had with software defect ownership was on a project for an embedded medical device. We actually had a team that managed the defects. The team even handled non-software defects since it was a system of which software was one component.

    We received feedback from the Help Desk - even had someone who represented them on the team. There was no way that they could be the defect owners based on the way the business was organized. Some in QA wanted to be the owners (there was hardware, software, and manufacturing QA all involved). But they could not effect the changes. Development was busy on the next release. It took a team that even included management to resolve the issues and prioritize the defects.

    Of course, not every situation will lend itself to such a process. Governmental regulation does add a level of bureaucracy and overhead that may not be best for everyone.

    Yet, having all of the affected groups participate in the decision making process does work. If a shop is having troubles in this area, enacting a Defect Management Team (or whatever it would be called) might go a long way to solving or helping solve the problems.

    Michael
    Michael L. Hovan
    mrschovan@verizon.net

  7. #7
    Senior Member
    Join Date
    Jan 2003
    Posts
    1,898
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    I believe ownership changes during the life of the bug. When first reported, the reporter "owns" the bug. The reporter is also responsible for documenting as much information as possible about the bug, which means, if it is the help desk doing the reporting, they need to at least be able to recreate the bug.

    After they report it, the development organization owns the bug. When the bug is fixed, it may be moved to a testing organization for testing. At that point, the testing group owns the bug. Again, if originally reported by the help desk, after the bug is retested and closed, and the fix moved into production, it is the responsibility of the original reporter to notify the person who called the help desk that their problem has been corrected.

    There may be many other areas that "touch" the bug; I just gave a simple example. Don't know if it helps, but that's my take on it!

    - Linda

  8. #8
    Junior Member
    Join Date
    Oct 2003
    Location
    Cali
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    thank you all for your detailed replies. I work for an insurance company as the Help Desk Manager and it seems everyone wants to dump the work on Help Desk because my staff is so cheap. They even want us to write the release notes.

    When I was working as a QA manager for HP, we owned all the bugs. bugs would be reported directly to the BA's or to the QA team and the QA team would manage the bugs to completion, which includes following up with developers the status of assigned work.

    All of your replies were very helpful as it adds reinforcement of best practices I have been employing.

    thanks.

  9. #9
    Junior Member
    Join Date
    Nov 2003
    Location
    Philippines
    Posts
    9
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    guys... do you have a sample QA Management Plan..? im starting a project and i need to formulate a QA Management plan.. dont have any idea on how to do it.. thanks....
    arun felix

  10. #10
    Senior Member
    Join Date
    May 2003
    Location
    Austria
    Posts
    1,480
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: BUG/Defect Management Workflow

    Originally posted by ljeanwilkin:
    I believe ownership changes during the life of the bug.
    <font size="2" face="Verdana, Arial, Helvetica">

    So it is also in my company. It's a very formalized life cycle in which only specific people (roles) are allowed to change a bug's state from one state to another.

    E.g. for my role as "Tester" I can submit new bugs or change bugs from state "ToTest" to "Passed" or "Failed". The bug life cycle ends in a release note (in which only "Released" Bugs may come in). So at the end it's the project manager who is interested in getting the bug forwarded from one state to another until it's "Released".

    Regards,
    Juergen

 

 
Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 8.33%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 05:07 PM.

Copyright BetaSoft Inc.