Warning: Illegal string offset 'filter' in /var/sites/t/theproactiveprogrammer.com/public_html/wp-includes/taxonomy.php on line 1409
As mentioned in my last post, us programmers are an easily infuriated bunch. Another thing which infuriates us is badly reported bugs. “The checkout page isn’t working”, “emails aren’t working”, “[enter feature here] isn’t working”. What then has to follow is an investigation to weed the required details from the reporter.
But what if you are given a bug to fix, and the reporter has left for another job, retired or off sick? What we really need is to foster an environment where bugs are reported properly, and this requires 3 pieces of information as a minimum:
1. Steps to reproduce
2. Expected behaviour
3. Actual behaviour
If you’re taking a bug report over the phone, probe for this information while you have the chance, and always include it in your issue tracking system. The best option is to be explicit about these three areas in every bug report, but if you prefer to use streams of natural language then at least make sure that this information is in there somewhere. Not only will this help others to understand the problem, but also it will lead to a quicker resolution and a starting point for testing.