22-04-08, 07:39 PM
Anybody who has written software for public use will probably have received at least one bad bug report. Virtual Web Designs are not exempted from this rule.
Reports that say nothing ("It doesn't work!"); reports that make no sense; reports that don't give enough information; reports that give wrong information. Reports of problems that turn out to be user error; reports of problems that turn out to be the fault of somebody else's program; reports of problems that turn out to be network failures.
There's a reason why technical support is seen as a horrible job to be in, and that reason is bad bug reports. However, not all bug reports are unpleasant: We currently maintain a lot of software, and we sometimes receive wonderfully clear, helpful, informative bug reports.
I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this blog before reporting any bugs to anybody. Certainly I would like every body who reports bugs to us to have read it.
In a nutshell, the aim of a bug report is to enable the software developer to see the program failing in front of them. You can either show them in person (Not always possible), or give us careful and detailed instructions on how to make it fail. If they can make it fail, they will try to gather extra information until they know the cause. If we can't make it fail, we will have to ask you to gather that information for us.
In bug reports, try to make very clear what are actual facts ("I was at the computer and this happened") and what are speculations ("I think the problem might be this"). Leave out speculations if you want to, but don't leave out facts.
When you report a bug, you are doing so because you want the bug fixed. There is no point in swearing at us or being deliberately unhelpful: it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help us by supplying all the information we need. Remember also that if the software has been supplied free by us, then we are providing it out of kindness of our own heart.
If you can find a list of known bugs, it's worth reading it to see if the bug you've just found is already known or not. If it's already known, it probably isn't worth reporting again, but if you think you have more information than the report in the bug list, you might want to contact us anyway. We might be able to fix the bug more easily if you can give us additional information.
We are in the process of writing our bug reporting system called VrBugTracker.
All our bug reports can be found at http://www.vrforge.net
Guide
• The first aim of a bug report is to let the software developer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
• In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
• When software does something unexpected. Do nothing until you're calm, and don't try and refresh the software.
• By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
• Be ready to provide extra information if we require it. We aren't being deliberately awkward. Have the software version number(s) ready, because we will we will need this. All software versions will be found at the footer of the page or in the admin side. If this is commercial software this will have vx.x, if this bespoke software it will have vwd-xxx vx.x.
• Write clearly. Say what you mean, and make sure it can't be misinterpreted.
• Above all, be precise. We like precision.
Reports that say nothing ("It doesn't work!"); reports that make no sense; reports that don't give enough information; reports that give wrong information. Reports of problems that turn out to be user error; reports of problems that turn out to be the fault of somebody else's program; reports of problems that turn out to be network failures.
There's a reason why technical support is seen as a horrible job to be in, and that reason is bad bug reports. However, not all bug reports are unpleasant: We currently maintain a lot of software, and we sometimes receive wonderfully clear, helpful, informative bug reports.
I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this blog before reporting any bugs to anybody. Certainly I would like every body who reports bugs to us to have read it.
In a nutshell, the aim of a bug report is to enable the software developer to see the program failing in front of them. You can either show them in person (Not always possible), or give us careful and detailed instructions on how to make it fail. If they can make it fail, they will try to gather extra information until they know the cause. If we can't make it fail, we will have to ask you to gather that information for us.
In bug reports, try to make very clear what are actual facts ("I was at the computer and this happened") and what are speculations ("I think the problem might be this"). Leave out speculations if you want to, but don't leave out facts.
When you report a bug, you are doing so because you want the bug fixed. There is no point in swearing at us or being deliberately unhelpful: it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help us by supplying all the information we need. Remember also that if the software has been supplied free by us, then we are providing it out of kindness of our own heart.
If you can find a list of known bugs, it's worth reading it to see if the bug you've just found is already known or not. If it's already known, it probably isn't worth reporting again, but if you think you have more information than the report in the bug list, you might want to contact us anyway. We might be able to fix the bug more easily if you can give us additional information.
We are in the process of writing our bug reporting system called VrBugTracker.
All our bug reports can be found at http://www.vrforge.net
Guide
• The first aim of a bug report is to let the software developer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
• In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
• When software does something unexpected. Do nothing until you're calm, and don't try and refresh the software.
• By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
• Be ready to provide extra information if we require it. We aren't being deliberately awkward. Have the software version number(s) ready, because we will we will need this. All software versions will be found at the footer of the page or in the admin side. If this is commercial software this will have vx.x, if this bespoke software it will have vwd-xxx vx.x.
• Write clearly. Say what you mean, and make sure it can't be misinterpreted.
• Above all, be precise. We like precision.
Support
Webnetics UK Ltd.
Webnetics UK Ltd.