|
|
Sometimes, a bounce-back PR can be sent back to development with the comment "It still doesn't work. I tried the exact same repro steps as before and it failed in the exact same way." But sometimes, the bug is slightly changed after the developer's fix. For instance, maybe the repro steps originally resulted in a crash, but after the developer's fix, the code now displays an error message saying, "Error #37 occurred". Or maybe the bug no longer occurs with the original repro steps, but very slightly different repro steps still result in the same behavior.
If the repro steps of the bounce-back are the same as they were before the fix, then the tester should say so on the PR and then send it back to the developer. However, if the repro steps have changed even slightly, then it's better to create a new PR and make a note on the old PR saying, "The original problem is fixed, but see PR #5741 for a related issue." The new PR should be completely self-contained and should have a full description of the bug without forcing the user to refer to the old PR. Trying to work both issues from a single PR often results in confusion and bad assumptions.
One time, a tester created a PR describing a complex bug that I couldn't reproduce. I asked her to check a Windows performance counter, and she reported that the counter was within the normal range. Eventually, I fixed the bug, but it bounced back with slightly different repro steps. The new repro steps were listed on the same PR, which by this point had grown very large, so I assumed her comments about normal values on the performance counter applied to the new repro steps, too. After all, she never posted a new note saying that her previous comment was no longer the case, so therefore I assumed it was still applicable.
But I was wrong—she hadn't checked it with the new repro steps, and indeed, that turned out to be the problem. My mistake cost me a lot of wasted time going down the wrong path. The next day, the tester and I agreed from then on, each bounce-back PR with different repro steps would be split off into a separate PR. That greatly reduces the risk of someone seeing a note in the PR about the original repro steps and incorrectly assuming that note is still applicable to the modified repro steps of the bounce-back.
Part of tech support's job is to help novice users resolve basic setup issues— everybody's heard the story of the customer who saw the message "Press any key" and called tech support saying he couldn't find the "any" key on his keyboard. But not all tech support calls are caused by user error or failure to read the manual. Many tech issues are caused by users reporting legitimate bugs in the product. In order to keep your customers happy, you need a process for communicating those bug reports between tech support and development.
One of the first things tech support does with a customer bug report is to find out whether the bug is already known by the development team. If it is, then the tech support rep immediately has news to tell the customer. In some cases the bug might even have already been fixed in a service pack that the customer hasn't yet installed. Or maybe the bug isn't fixed yet, but is scheduled to be fixed soon. Or maybe the bug has a relatively easy known workaround. Or maybe the bug isn't technically a bug at all, but merely a very commonly reported user error. Or maybe the development team knows about the bug and thinks it will be impossible to ever solve.
But regardless of whether the news is good or bad, at least tech support will be able to tell the customer something. Customers can barely tolerate reporting a bug and then hearing a worst-case response of, "We're sorry, it's impossible to fix that." But what they really can't stand is reporting a bug and then hearing nothing at all. Almost as important as fixing the customer's bug is managing the customer's expectations about when to expect that bug fix, so your tech support personnel need to have access to all the information about each bug. Storing this information in the tracking system is the easiest way to accomplish this.
| Tip |
I once had a major customer demand hourly status reports about a bug. Clearly, this was an unrealistic expectation—we need at least a full day to properly test even the smallest hotfix, so hourly reports were overkill. Still, it demonstrates how anxious customers can be to hear when their bug will be fixed. Make sure your tech support can report something to the customer within 24 hours, even if it's nothing more substantial than "The developers are now investigating the issue and we'll let you know more as soon as we can." |
The search features of the tracking system should allow tech support to easily discover whether a bug is already known. In fact, a competent tech support team can even use the tracking system proactively by reading all the deferred PRs before the product ships, and preparing answers for those issues that a customer might encounter. On the other hand, if the customer reports a bug that isn't already known, tech support can simply create a new PR and communicate the appropriate level of urgency by setting the priority field.
For various reasons, many development organizations often accidentally leave tech support out of the loop on the status of most bugs. But in order to do their job correctly, tech support needs the knowledge contained in each PR. Unless your team is willing to answer dozens of questions each week, be sure your tech support department can access your tracking system.
|
|