Page 1 of 2 12 LastLast
Results 1 to 10 of 13
  1. #1

    Developers changing bug information

    Hi all!

    I'm curious to hear your responses to my current issue. We are using a bug DB to track all of our defects. Most of the defects that are found are by black box testers so the summary and the description of the bug is typically in user-functional terms.

    There have been recent discussions about allowing developers to modify the summary of bugs with more technical information so that when working thru their bug lists, they have more information about the bug in the summary.

    My initial reaction is to protect the bugs from allowing them to be changed by development, and only allow developers to enter comments, but there are some pretty passionate developers that want the ability to modify at least the bug summary..

    So, what are the pros & cons of allowing this? Anyone have any experience that they can share. I'm sure that there is an amicable solution somewhere out there!


  2. #2

    Re: Developers changing bug information

    Ideally (in my opinion), the developers should be able to append information, but not change/delete any. Whether this means you need a new field for "Developer Analysis" which will display in the reports right after the problem description, or a way to allow the developers to add comments to the problem description without being able to edit the prior information is dependent on how you bug tracking system is implemented.

    Our (proprietary in-house) system allows each such comment section to only be appended to with date/time-stamped entries via pop-up dialogs. So elligible users can continually add to certain sections, but they cannot delete existing comments.
    web site | [url=http://www.ebookworm.us/[/url]

    [i]...Sound trumpets! Every trumpet in the host! / Sixty thousand, on these words, sound, so high the mountains sound, and the valleys resound.</i] (The Song of Roland)

  3. #3
    Senior Member
    Join Date
    Jul 2002
    Albany, NY USA

    Re: Developers changing bug information

    Ask the developers if you can modify some of their code to make it easier for you to read. [img]images/icons/smile.gif[/img]

    I agree w/ Charles. I would just add that you should consider the intended audience -- who reads the bug summaries? Do they become part of any documentation? If they are solely for the development team, that would be the only exception to the "no edit" rule. On the other hand, if they become part of the release notes, protect them.

  4. #4
    Junior Member
    Join Date
    Aug 2001
    Richmond, B.C., Canada

    Re: Developers changing bug information

    Not to be the only paranoid here :-) but if they are able to alter any field, they can make changes to the bug so that it's easier to fix, to justify their changes, to put blame elsewhere..etc...
    I've worked with some really classy developers who only want to fix the bugs properly, but some in the past have been really spiteful and would think nothing of altering the bug to make their life easier.

    They should only be able to append/comment...most db's have this capability, along with security to assure proper user group rights.


  5. #5

    Re: Developers changing bug information

    The strategy that we took was to allow comments to be added only (ie., not updated) complete with a record of the date/time and user, this preserves a full audit trail of all information associated with the bug. Only users with the appropriate authority (manager role) can change the bug summary, this allows controlled update to a field that does require meaningful information in summary reports, etc.

    I would suggest that update access to the bug summary is controlled and if developers want a summary changed then they make a request to person with access to make the change after approval. If the test team is entering sensible descriptions in most cases then these requests should be limited.

    http://www.ozibug.com - quality web based bug tracking

  6. #6

    Re: Developers changing bug information

    Tester often need end-user type information in order to reproduce bugs.

    Debuggers often need more technical information.

    Perhaps you could add a new "Technical Summary" field for the developers to use?
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  7. #7

    Re: Developers changing bug information


    I would just say no.

    I've run into this situation several times and what happened was they put in a lot of technical jargon that the users didn't understand, and wordsmithed bugs to make them sound less serious. In one case, once we upped their authority levels, they went in and changed all of the severity levels, including closing of bugs that were not fixed and retested. It was a mess.

    I think Joe's suggestion sounds good; otherwise, most defects contain a comments field and that should be sufficient. Any technical staff should be capable of finding and reading the comments section for further technical information.

    The development staff in every case was "passionate" about getting their authority expanded, so I understand your dilemma. I've given in on this one several times and have been sorry in every case.

    - Linda

  8. #8

    Re: Developers changing bug information

    Yeah, your developers are not displaying a professional attitude at all.

    I don't know of any engineering, legal, financial, or other professional system of record keeping where records are erased or modified instead of appended to. Accountants for example can't go back and overwrite mistakes, they have to make correcting entries. Doctors don't go back to their original patient interview notes and change them based on whatever some test finally determines, they keep all that stuff to maintain a record of what was done and why.

    Anyhow I guess my only practical thought is what's making them so hot to remove your testers words? Is it possible the entries aren't being made in neutral non-judgmental language. What I usually want to see in bug entries are the plain unadorned facts in point form, then perhaps an explanation about how the defect might affect users if helpful, that's it, generally no direct references to other people, no emotional commentary. Just a thought.

  9. #9

    Re: Developers changing bug information

    Well, if it is editable, it will be edited, it is as simple as that.
    So, if you want something read-only once it is written and want to keep a complete log, then you need find a tool that can do that. Depending on people to not change something that they can change will certainly fail. But on the other hand, you have to trust people.
    By the way, I do not think all need to be in the change log. For example, someone filed a bug and put it in the OS of Windows, but it turned out to be OS independent. I would rather just change it to "OS independent". Maybe not a perfect example, but what I am saying is that, not all need to be logged.

    Please take a look at Bugzero

    It keeps a complete, read-only description/response history log. But by default, the one line summary can actually be changed without logging (you can make it read-only though). Here I guess people need to be trusted to do the best to make the bug report best described in a few words.
    qa AT websina.com

  10. #10

    Re: Developers changing bug information

    I disagree with almost everybody... partially:-)
    Usualy, people in the projects use the summary reports, so the summary lines, as a quick listing for information. Then it's important to have good summary lines to get a quick picture of the open defects.

    In any organization it happens that some defects may be reported un-acurately. So if it can help improving things, the summary line may need to be changed sometimes.

    Now you can't leave the developpers do whatever they want. I would say that you should enable someone among the defect workflow actors to the role of modifying critical fields.

    In project I worked, usualy the Project Manager or the SQA responsable had this ability on request from the developper.

    I hope it helps,

    Raynald Korchia


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
BetaSoft Inc.
All times are GMT -8. The time now is 04:05 PM.

Copyright BetaSoft Inc.