What happens when a defect in software is discovered? When Quality Assurance process is implemented properly, it is first reported to an issue tracking system and then is (usually) fixed. This is common knowledge in the software development business, but what is not, is how much of a difference does a proper reporting make.
A bug ticket raised ‘in a hurry’ or by an inexperienced person usually contains too little information about a defect to be useful for a software developer responsible for fixing it. This results in time being wasted in one way or another before finally all the required data is gathered and a fix can be prepared. Such inefficiency can be avoided by making sure that information included in a ticket can answer a few simple questions.
What isn’t working correctly?
A brief and concise title for a defect is something to strive for. Most of all, however, it should convey the nature of the problem – the ‘what’. After all “Logging in with valid credentials returns a xyz error” is more informative than “Login doesn’t work” or “Issue #359”.
Any detailed information which won’t fit in the title should be included in the actual description section provided by the bug tracking software.
Where has the problem been noticed?
When applied to a defect, this question inquires about the ‘location’ where it has been encountered. Details such as software’s version/build number, environment (mock, staging, production, etc.), web browser, screen resolution, make and model of a mobile device, OS, specific test account used – these will change depending on the type of software application, but all constitute the so very useful ‘where’.
When does the issue occur?
What did you EXACTLY do to encounter the bug?
Is it always triggered when those steps are repeated or only every now and then?
The detailed description of actions performed by a user which manifested in the faulty behaviour of the software falls under ‘when’ category.
Information gathered here is, perhaps, the most crucial, because of its irrevocability to the reproduction of the issue. And if it can be reproduced by the developer assigned to fix it – then likely it will be resolved sooner rather than later!
Last piece of advice
A picture is worth a thousand words, so is a screenshot or even a video recording – especially since some defects aren’t easy to describe. Therefore including them (along with the crash logs in any case of those nasty crashes!) goes a long way towards reporting bugs the right way and assuring the quality of a software product.
