- Business Intelligence (BI) Systems
- Cemetery and Funeral Director Management System
- Construction and Project Management
- Customer Relationship Management
- Enterprise Resource Planning
- Financial Management
- Information Media and Telecommunications
- Professional Services
- Retail Trade
- Supply Chain Management
- Warehouse Management
- Raving Fans
- About Us
- Contact Us
Submitting a Bug Report
By Enabliser Dan
Good software goes through extensive testing and checking before release. While bugs are normally rare, sometimes you'll find one in even the best system. If it seems important, then you'll want to tell someone about it. The purpose of a submitting a bug report is not to report the bug – it's to get the bug resolved. If the developer can reproduce the bug then your chances of that happening are greatly improved. As a software developer I've come across a lot of bug reports. Some are better than others.
A good bug report contains four things:
1) The exact version of the software you're using. For example, saying Application XYZ is not sufficient. You need to say Application XYZ 6.1 PU1.2. You can find this in Sage 300 ERP, for example, by selecting Help, System Information.
2) What you did. Try as best you can to remember what you did and, if possible, try doing it again and writing down the steps you did. Screenshots are good. Put the screenshots and any other information into a Word document.
3) What happened. “It didn't work” is not very helpful. “It said 0 records processed” is better. Screenshots can be helpful here too.
4) What you expected to happen. Sometimes what you expected to happen is not what was meant to happen and this can indicate that the wording on the screen might need to be altered to be clearer. If it involves amounts, then saying the amount you expected can also be helpful.
And a bonus tip – proof read your report before sending it. I've seen several bug reports that don't make any sense because the sender didn't proof read.