This blog is in continuation to the last blog that I wrote about Reporting Quality Bugs, which discussed what a quality bug is and the factors that influence the quality of a bug report. In this blog post I will be discussing the fields that would constitute a quality bug report.
As already emphasized enough in my last post upon how crucial a role does a good bug report plays in saving time and effort, enlisted below is a list of fields that I perceive no bug report should risk to miss!
Intuitive Titles
The quality of a bug title is often overlooked as merely a way to separate bugs from each other but the title of a bug plays an undeniable importance in the overall quality of the bug. An appropriately crafted bug title has to be concise, yet descriptive enough to carry all the necessary information. It should describe the underlying problem and not symptoms. The title indeed is the first thing any developer notices about the bug and attempts to get a moderate idea about what the bug is about, which software layer or component this issue could have surfaced in, the efforts required for estimation, severity, etc.
If given a standardized structure to bug titles, it could also help ease the efforts in discovering if the bug have already been reported. This of course saves a count on duplicate bugs and repetitive efforts on both the testers and developers ends. To give an idea, there is an article on Writing The Perfect Bug Title which could be referred for a starter.
Not to mention a QA engineer's experience and understanding of the domain and the issue itself plays an important role in crafting an appropriate bug title and the report.
Elaborate Descriptions
An elaborate bug description would comprise all the preliminary investigative details besides actual and expected results. This would help describe the bug as precisely as possible and help developer understand the issue faster and better. Not to mention the description should include only useful facts and not opinions and complaints. Though IMHO "opinions" and "suggestions" aren't bad when it comes to suggesting a lead but they definitely are better suited for the comments section and not the bug description.
Taking enough time for detailed investigation would not only help describe the bug more precisely but could also suggest the cause of the bug to certain extent. To an indolent it may seem like too much of an activity for a QA engineer but trust me any experienced QA engineer would count such an investigation intriguing. Not only does it saves a lot of time and effort in resolving the issue but also contributes to understanding the domain and the product better plus improved testing skills.
The investigation details must also include the environment, such as, OS platform, user agent, etc. for it is be possible that the developer may try to reproduce the issue on a different environment stack and may end up claiming the bug as non reproducible costing further investigative iterations. This may require testing the bug in other relevant environments.
Bug description should also include all the possible workflows in a product where the same issue was found. This will not only save the count on the number of bugs reported but would help the developer come up with a better solution by drawing attention to probably a wider prospective?
Steps To Reproduce
Clearly defined steps to reproduce an issue in a given environment undeniably gets an issue reproduced consistently, debugged and resolved quickly. If the bug is found in other product workflows, steps to reproduce should take them into account as well.
Severity
Severity not only suggests how critical the bug is but also in a way conveys the priority at which the bug needs to be fixed. As already discussed in my last post, mentioning incorrect bug severities results in deprioritization of relevant bugs, contribute to incorrect development status and not to mention an unhealthy criticism of development team.
Although it is understood that marking an appropriate severity needs good domain knowledge which takes time to build, a consistent effort is nevertheless expected in that direction.
Project
The project field mentions the name of the project to which the bug belongs to. It also allows to filter list of bugs by project name.
QA Owner
A bug report should always mention a QA owner responsible to test it. It is him whom everyone else should be able to reach out to for further clarifications of doubts. A QA owner need not be the one who reported the bug but instead the one who is responsible to make sure that the bug is thoroughly tested in further releases.
Necessary Attachments
Attachments support the fact that the bug reported indeed occurred in cases when it can't be reproduced consistently. Not to mention if a bug is not reproducible and there are no relevant attachments to support the occurrence of the bug, then all testing efforts used in finding, investigating and reporting the issue would be wasted.
Relevant attachments also gives an opportunity to the developer to start investigating the issue before even attempting to reproduce the issue on his local development environment which may involve certain ceremony to prepare for the same, such as, checking out particular tag or a branch locally, orchestrating the reproduction of the issue, etc.
Depending on the nature of the bug, attachments may include system logs, crash log dumps, trimmed screenshots, screen recordings, etc.
Tag/Release In Which The Bug Was Found
All the relevant tags or releases in which the bug was found and reported. This is the most important field I am sure that everyone would agree to. Without it the origin of the bug is unknown and can't either be debugged and fixed straight forwardly. The only way out would be to try reproduce it in all relevant builds and then decide the release in which it should be fixed. This clearly is unnecessarily tiring and time consuming.
Tag/Release In Which The Bug Is Expected To Be Fixed
Based on the severity & business expectations a tag or release can be specified in which the bug needs to be fixed. But I am not sure if the tester can make this decision all by himself. At least not unless he is very clear on the current business expectations and criticality of other bugs or feature request which clearly is product owner's cup of tea. What a tester may least expect is a fix in the next planned release which is what he can mention and leave it up to the product owners to decide if they wish to make changes to this field as they deem fit.
Tag/Release In Which The Bug Was Fixed
All the tags or releases in which the bug fix was made available. This field needs to be updated by the developer who fixes the issue. Obviously owning to time availability or other business specific decisions, the expected and the actual releases may differ.
Pull Request
IMHO it is a good practice to mention pull requests in the bug report upon fix. Though they don't contribute to defining bugs but they certainly provide a great way to refer the actual fix that was made in case the bug is reopened or for any other relevant reasons which otherwise would take time and effort to figure out.
Comments
Though comments don't contribute to defining bugs just like pull requests but they offer a great platform to discuss progress on a bug. A bug typically goes through an investigation phase and may be held for fix in some later point in time. Logging investigative details as comments helps save time by avoiding reinvestigation by other developer who may be decide to fix the bug or by the same person for he may have forgotten it all by the time he decides to fix it. It will also keep other stack holders updated upon the progress. Comments could also be used to communicate opinions and suggestions.
Conclusion
Amongst the list of fields enlisted above I have deliberately skipped to mention certain fields that convey the progress of a bug for I don't consider them as crucial. Moreover, this IMHO is a list of absolutely crucial fields that must constitute a bug report, including other acritical fields here would dilute the criticality of the ones enlisted already.
Some of the fields that I consider acritical in current context would include, sprint details, creator of the bug, bug history, assigned developer, estimated effort in hours, hours spent to fix the bug, etc.
A bug typically goes through different phases of progress and investigations by different developers and testers throughout it's life. This undoubtedly builds up to various insights and wider knowledge in and around the issue that I think should be responsibly documented in the report by everyone.
The quality of a product can be assured by keeping bug standards tall enough.