Quality of a bug is indispensable.
In this blog post we will be discussing what a quality bug is and some factors that influence the quality of a bug. In a subsequent blog post I will be discussing what in my opinion would comprise a well documented quality bug. Please be informed that I am no tester by profession and that this post is an opinion mostly from a developers point of view after working closely with various testing teams over relevant number of years in the software industry.
What does quality of a bug mean anyway?
Success of a product can not be credited only to code craftsmen but in fact is an outcome of crucially complementary efforts from both testing and development teams. There has never ever been any software developed bug free. As we all know, it's inevitable. Discovering as many bugs before the product actually hits the market saves the company from serious embarrassments and keeps the clients confidence high.
Every development cycle has probability of introducing a new set of bugs and hence it's crucial that every production release is well tested to assure a quality delivery. This, however, has to be achieved in the most reasonable time and it is a well investigated and well documented issue besides many other factors, of course, that would help both the development and testing team achieve the same. Such a bug is what I call as a Quality Bug.
A quality bug not only conveys the issue precisely but also saves time and effort while troubleshooting the reported issue. Reporting a quality bug however takes more time than simply noticing an issue and reporting it without making considerable investigation efforts and crafting an appropriate title, etc. Such poorly crafted bugs takes toll on overall delivery time and effort.
What factors influence the quality of a bug and what are the implications of poorly crafted bugs?
IMHO the factors that influence the quality of bugs includes:
-
Experience of a tester
Tester's experience which is reflected in his understanding of the domain and more importantly in his attitude and approach towards investigating an issue contributes significantly to the quality of reported bugs.
It is also needed to be understood that it is the attitude and approach towards investigating an issue that contributes to building tester's domain knowledge which in return augments and helps refine his bug investigation strategies. A tester without the right attitude towards issue investigation must have poor domain knowledge as well which eventually affects the quality of the bug and product delivery itself.
Although issue investigation is not attributed to one particular party, a developer or a tester, but investigating a bug at the earlier stage of a bug fix cycle would save a lot of time and effort by conveying the issue as precisely as possible.
Investigation, in particular, would include digging relevant logs, verifying the issue against different set of data and across various releases, etc.
-
Tester's attitude towards bug documentation quality
Quality of document of the reported bug is very crucial to the quality of the bug itself. It must convey the issue as precisely as possible keeping in mind that this document has to be referred by many other people throughout it's lifetime. A poorly documented bug would waste a lot of time by requiring everyone involved in fixing, testing and referring that bug to reach out individually to the tester who reported that bug. This introduces a chance of everyone comprehending it differently which may eventually result in a poor fix and testing too. This may soon build up frustration in the team if there are huge number of bugs and every other bug is poorly documented.
-
Time available to complete the testing cycle
Although it is understood that the detailed investigation probably may not be possible while testing if the testing team has limited available time but I would like to stress here that the quality of the documentation must never be compromised. As already suggested that a poorly documented bug eventually results in overall slowed progress and frustration.
-
Tester's appraisal criteria.
There is definitely a lot more to a tester's appraisal criteria but undoubtedly a tester's effectiveness is also notoriously gauged by the number and severity of the bugs reported. It is IMHO that these two criteria are hazardous to the very essence of quality bug reporting.
Although as already mentioned that discovering as many bugs as possible in every test cycle saves the team and the management from embarrassments before clients, I firmly believe that discovering the number of bugs and discovered bug's severity should instead be one of the testing team's motivations but never a part of tester's appraisal criteria. It is these appraisal criteria that result in poor investigations, tester's domain knowledge and the quality of the reported bugs by turning motivation into hasteful competitiveness. The spirit of discovering as many bugs as possible and as severe bugs as possible should never overshadow the significance of appropriate investigations and the bug documentation quality itself.
Wrongly pronounced number of bugs and bug's severity will not only result in deprioritization of really relevant issues but would also conveys wrong development status of the product before the management. Not to mention it may result in unhealthy criticism of the development team and spoiled relationship between both the teams.