Unreproducible Defects

I’m writing this second blog post as an example of a post not directly related to process. While many of these posts will be process related, these posts are simply thoughts and ideas that I’ve developed over time.

One common occurrence in software development is the case of unreproducible defects. Especially when reported by a customer, how do you go about resolving this bug ticket? First, obviously, you *do* try to reproduce the issue. The engineer and tester most familiar with the feature should be the ones working on it. However, use time boxing to prevent spending too much time attempting to reproduce the issue. The next step is to obtain more information from the customer. However, in many cases this is not possible. So, what do you do? As the engineer you then review the code. Thoroughly comb through the code with this specific defect in mind trying to imagine how on earth such a defect could occur. Specifically think about race conditions and timing issues. You should be able to find a defect, a possibility, with regard to how the customer-reported issue could have occurred. Then you fix that defect knowing that it may not be *the* defect and report the issue as fixed. Will the defect come back? Possibly. But you’ve done several things: you’ve fixed an issue, you’ve become more familiar with the code, you have trained your mind to think about those hard-to-catch race condition bugs, and you don’t have lingering bug reports. Do not simply put the defect in a “watch” state and close it as “unreproducible” after a fixed amount of time, say 3 months. Yes, I’ve worked at companies with this policy. Think about this from a customer’s point of view. No response for three months, then finally a “we were unable to fix your issue” response. The impression received by the customer is that your company doesn’t take requests seriously and are not capable of fixing issues. However, by closing the issue as fixed, won’t the customer be annoyed if the defect still exists? Perhaps. But this time, if the customer sees the issue again, they will be more apt to report the issue again and, hopefully, with more detail. Why more apt? Because they see that your company is responsive, diligent, and attentive to customer requests, which is key here. Do not sit on bugs, especially customer-reported bugs, for long periods of time. In sum, fix a bug related to the issue (hopefully it does in fact fix *the* issue, but perhaps not), don’t lazily place defects in “watch” states, and never ignore your customer.

Leave a Reply

Your email address will not be published. Required fields are marked *