Writing A Good Bug/Fault Report
The aim of this post is to encourage the use of various tools, methods and practices to increase the quality of information WebTechGlobal receives from Beta testers when about to release new software.
This information is being written to support WebTechGlobal Beta testers who are testing Web related software, mostly WordPress plugins; not desktop software. The advice and knowledge used may not apply to all types of software or development. The information is meant for users who are very new to the concept of communicating with a developer, not exactly something everyone doeso in every day life and depending on the developer or the user the communication can breakdown fast. Debugging can be impossible at times. The users interpretation of a fault will vary, how they deal with it and report it will also vary. A developer receiving details about any faults in software may also misunderstand what the user is actually trying to communicate.
Why take the effort to send a good fault report?
Emails or tickets can be very time wasting when they do not contain enough information or misguide developers. Forum threads claiming all sorts of faults/bugs which are a result of an earlier fault are very damaging to the future of a product i.e. a single fault happens, possible something very unusual, the applications stored data is effected and then causes a chain reaction of problems. In reality there is only one fault, sometimes even user error and it is important I establish this quickly. The ideal report is very detailed, laid out in a way that is easy to read, images attached, noticed thrown out by the application pasted and maybe even a video to show the steps taking by the user. Videos are perfect but take time, also good software for it usually costs, someone please correct me if I’m wrong I’ve been using the same software for 2-3 years now.
Beta Testing Conditions
I would like to take the chance to mention the main conditions applied to Beta testers and remind you all.
- All reports must be sent by the email address provided on the interface of the application or an email address you have received communication from regarding Beta testing.
- Do not create forum threads regarding beta faults/bugs.
- You can create forum threads for general beta advice i.e. where to test, how best to test something, where to get test data or files.
- You are not permitted to upload videos for public viewing. If you can ensure the video is hidden from public, even restricted to just a friends/contacts list then this is acceptable. It is important that Beta testing videos are not mistaking for the final product or even seen once the final product is released.
- Thank you for your co-operation, if we work together I can deliver and provide Beta testers with a discounted software. Discounts start at 50% off.
Tools
The first tool I want to promote is to encourage users to take screenshot. This is common but not common enough, sometimes users don’t even copy and paste a notice/error. Sometimes there may not be one to copy and paste. In either case a picture tells…, you get the point. Here is a browser extension I recommend and use a lot myself…
Pixlr Grabber
“Grabbing screens and pulling images from the web just got a bit easier. With the Pixlr Grabber add-on, you can copy, save, share or even edit your final grabs – including any image or background – with just a right-click.”
Select the browser you use for testing web software…
- Google Chrome
- Mozilla Firefox
- No other browsers currently supported
- Official site for Pixlr Grabber
If you know of any other good software that is free, easy to user and quick to install please suggest it by commenting below.
Fraps Screen Recorder
This is a screen recorder recommended to me many times. Even a 10 second video can help. 10 seconds is quickly uploaded, obviously not public.
Click here to go to the Fraps Screen Records
Advanced Contact Form
As I write this I’m also working on an advanced contact form that adapts depending on the reason for contact being made. A critical part of this form is bug reporting features. It will have form fields for specific information, you may even be reading this from the screen that has that form. I intend for the form to automatically attach a screenshot with the screenshot itself being created automatically also, all possible with PHP and Javascript but it is slightly complex. For now it is form that adapts, please use this form if it exists in the application you are testing. It will send the report to where I want it to be sent too, usually by a SOAP API, which is secure, direct and very easy for you.
A bug report button will also be put on most of my applications screens. Information regarding the screen you are on when clicking the button will be sent with the report. This will save you explaining these details. The information will be stored on the WebTechGlobal server, in a database for fault reports. The information can then be crossed referenced and I can easily detect when a single issue arises more than others. Allowing the proper priorities to be applied.
Other Features of The Contact Form
- Can select priority level, Beta testers need to indicate the most serious issues by selecting High priority.
- Can select methods. Sometimes users won’t have a choice though. When a user has a choice, they may select Email, Forum or Ticket. The ticket and forum options makes use of Web Services, SOAP API.
- Can opt to send sensitive data including FTP login, admin are login, hosting login etc.