Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I agree with Jon Limjap - your QA personnel must be competent enough to post appropriate bug reports, given the right basic training and guidelines. Nevertheless, there are ways to enforce and encourage better bug reporting:</p> <ul> <li>Most bug tracking software have a way of marking some fields of the bug report as mandatory, so that the reporter has to actually choose the appropriate value in order to successfully create the bug</li> <li>There is usually a possibility to include a basic template for the bug report, something in the lines of</li> </ul> <blockquote> <p>Scenario:</p> <p>Expected Results:</p> <p>Actual Results:</p> <p>Remarks:</p> </blockquote> <ul> <li>You can (and should) provide a bug-reporting tool that will be run on the problematic machine, gather the relevant information and pack it into an archive file (and maybe place it on the desktop). You then instruct your staff to run it whenever they encounter a bug they wish to report and attach the archive to the bug. This tool should be easy to use (just running an executable) so that they would attach the diagnostics information to any bug without having to think if it is relevant or not. This tool is usually also very useful with customers.</li> <li>Last but not least - "education, education, education". People learn the best from experience - just make sure that whenever someone opens a bug without the proper information included, the person handling the bug would go and talk to the one who opened the bug, and explain what is missing and why it is important.</li> </ul> <p>These are practices we have been using quite successfully in my current workplace and I believe them to be quite universal to fit to most working environments.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload