Fixed or Not Repro

Recently I opened a discussion on the Microsoft responses to issues posted in the PFC. One question we’ve been grappling with that’s related is how to resolve bugs that repro on the original build the customer reported the issue for, but on our latest internal builds, it doesn’t repro anymore.

 

Should bugs that don’t repro on new builds be resolved as “Fixed” or “Not Repro”?

 

The reason the bug no longer repros may be because the developer noticed it an fixed it without logging the bug (hence we wouldn’t have a duplicate) or the bug could have been caused by a build integration issue that has since been resolved.

 

I’m inclined to resolve the issue as Fixed since it does repro on the original build and seems to have been somehow fixed in the meanwhile, even if we can’t necessarily pinpoint the fix. What are your thoughts?

 

Thanks,

Marie Hagman

Visual Studio

Program Manager

Comments

  • Anonymous
    February 18, 2005
    You shouldn't resolve as fixed if you can't pinpoint an actual fix that was checked in. For all you know, the bug may still exist, but be masked by some other behavior now, or may still repro but not as frequently on more recent builds.
  • Anonymous
    February 18, 2005
    Don't even bother fixing it. Your customers don't know any better.
  • Anonymous
    February 18, 2005
    Michael is exactly right. If you can't directly identify the change the fixed the bug, then it's become a no repro.

    When your test team does a regression testing pass, they should treat "no repro" bugs with more suspicion than "fixed".

  • Anonymous
    February 19, 2005
    It isn't fixed unless you know what you did to fix it. I'd mark it "no repro" and as Bruce says, those bugs need to be looked at VERY hard by the QA folks.
  • Anonymous
    February 19, 2005
    The comment has been removed
  • Anonymous
    February 20, 2005
    Thanks for the input and I like the definitions from AT.

    How about this:
    - if the person resolving the bug in question knows for a fact the specific problem was in fact fixed, resolve as "fixed".

    - if the bug does not repro on the latest build for an unknown reason, resolve as "not repro"

    Some people argue that customers want to see their bugs fixed so if it in effect is (ie no longer occurs) then "fixed" is a more amicable resolution then "not repro". Based on the feedback it seems you would prefer the most precise resolution.
  • Anonymous
    February 21, 2005
    I like AT's idea.
    Although what i've seen through posting in the PFC that resolved bug, or added suggestion don't seem to take into account, older suggestions, or bugs that were resolved as won't fixed. Since from my experience, different teams take different bugs they might not be aware of newer solutions that might eliminate a ceratin old bug, or give newer functionalities. My 2 cents. ;)
  • Anonymous
    February 21, 2005
    Here i drop you a bug, that might have not been understanded by the team. And the resolution doesn't take into account new feature that has been fixed. ([DesignerSerializationVisibility(DesignerSerializationVisibility.Content)])
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=8195566b-639e-4a0c-8552-0955b03882fe
  • Anonymous
    February 22, 2005
    If it doesn't repro in latest build, always say it if it's going be tagged as "doesnt repro". Then the user who submitted it has the responsibility of leeching the next public build and checking whether its fixed for real or not.
  • Anonymous
    February 22, 2005
    It would also help if the PFC was a bit more flexible:

    User A opens bug.
    The Bug is closed at date X.
    User B has a newer build (from date X+Y) and noticed the bug is still there, what to do? He can't re-open this as the owner of the bug is someone else.

    There should be a system that allows re-opening by other users atleast if they have newer build and that the comments by other users would also be very visible to the MS people even if they do not bother going to PFC. If I understand correctly only the bug's submitters notes are visible internally?
  • Anonymous
    February 23, 2005
    The comment has been removed
  • Anonymous
    February 23, 2005
    The comment has been removed
  • Anonymous
    February 23, 2005
    Just in case, if anyone needs to contact me.
    (First time posting around this stuff.) My e-mail. nelak@ciudad.com.ar
  • Anonymous
    March 07, 2005
    Knight - we've been discussing a feature just like the one you described. We would really like to know what customers think about the resolutions and responses MS gives to bugs. An "escalation" button for customers to be able to say "hey, I'm not happy with this, I want to escalate the issue" is one idea. What do you think of this?
  • Anonymous
    March 07, 2005
    Sounds great, since this weekend some of my posting have also became closed, some without a satisfactory answer. I would come in real handy, especially since Beta 2 should be coming along soon.