Pop quiz: A tester finds and logs a bug. Some days (weeks (months)) later a developer picks up the bug and runs through it. Lo and behold, the bug does not occur. What should the developer do with this bug?
Most common answer: Resolve the bug as “No Repro” and send it back to the tester. Bzzt! Wrong! An electric shock to that part of your body you care most about. The bug jolly well does repro or I wouldn’t have logged it. Use the build I was using when I found the bug and I guarantee it will reproduce.
Less common answer: Resolve the bug as “Fixed” and send it back to the tester. The bug used to happen but now it doesn’t, so I guess this answer is technically correct. You still get a cattle prod between your shoulders, though. The bug may in fact be fixed, but it’s just as likely to still exist and merely be hiding behind some other bug.
Extremely rare answer: Install the build on which the bug was reported and verify it does indeed repro on that build. Next, binary search the daily builds (you do build your full product at least once each day, right?) until you find the build at which it stopped repro’ing. Binary search through the checkins for that build (a simple process if you run every checkin through a full build) until you find the checkin that “fixed” the bug. Figure out why that set of changes caused the bug to no longer repro. This is the first point at which you have enough information to validly resolve the bug as Fixed. Of course, it’s just as likely that the bug is still lurking somewhere. If you find this to be the case, your tester will be more than happy to help you find it again.
Resolving a bug “No Repro” just because it doesn’t repro on *your* machine is a sure way to make your tester grumpy.
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a tester and my team needs program managers. Great coding skills required for all positions.