Creating a Good Support Ticket

The most difficult part of customer support is recreating bugs, not fixing them. Some bugs are difficult to find even with a good support ticket, but an imprecise support ticket makes finding the bug harder, and takes longer. In this article, I'm going to explain the information that I (or someone else providing NCover support) ask for in response to a support request, and how those pieces help me figure out what's wrong. I'll also point out what information creates a good support ticket.

Basic Information

The very first thing that should be included in a support request is complete console output from NCover. If you normally run NCover from NCoverExplorer, NCoverExplorer has a "Command Line" generate option that you can paste into a console window to generate console output that you can then copy-and-paste into the support request. Having NCover's console output tells us which section of NCover the bug is likely to be in, shows us how NCover parsed the command line, and sometimes tells us which method the error occurred in.

NCover's command line options are next on the list. Whether they are typed into the console or within a settings file, the command line options help us recreate NCover's running environment and also tell us which parts of NCover can't cause the problem. If there are no exclusion options, for example, then the exclusion logic isn't faulty.

If you're running NCover as part of a continuous integration setup, we may ask for the relevant portions of your NAnt or MSBuild script. NCover comes with dlls that let those scripts call it, and errors involving NAnt/MsBuild scripts usually mean that the dll isn't correctly passing the options in the script along.

We'll almost always ask for a verbose log file. NCover runs a client program inside your application that actually gathers the raw coverage data, and the log file is a message log from that program. The log file says what options the application was given, and keeps track of which modules were loaded. The verbose log reports detailed instrumentation data, as well as class and method loads. It's as close to stepping through the program as you can get without a debugger.

In some cases the error looks familiar, but we're not sure if it's something we've seen before or whether it's totally new. In those cases, we'll ask what version of NCover you're using. We'll also ask for which version of Windows you're running, even to the build number (we always tell customers how to find unusual information), and whether you're running on a 32 or 64 bit version of the OS. Since NCover requires Administrative privileges to run, we also ask whether you're running as a Standard User or not, just to make sure.

If the error is in the HTML report, we'll always ask for your coverage file, because in-house we can use it to generate a report and step through code if we need to. In very rare cases we might ask for the source code that manifests the problem; some bugs were obvious after looking at the source code and impossible to find beforehand. In general, however, we try to stay as far away from your source code as possible.

Conclusion

With all of the information represented above, we can usually figure out where the error happens and then fix it. Sometimes however, support requests come in that say "NCover crashes on my program!" or "My coverage file is empty!" or just a paste of NCoverExplorer's exception screen. We respond to those cases quickly, but we could have sent a solution, not a request for more information, if they had just included a log file, the complete NCover command line, and the console output.

In summary, a good support ticket includes