Bugs Should Always Be Tracked
Bugs Should Always Be Tracked
It pays to err on the side of more tracking than less tracking when it comes to flaws in software—and anyone who is the gatekeeper of the quality of software should have the utmost concern for tracking a software project’s flaws and preventing their recurrence.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
Many of us in the software development field take things for granted. I was reminded of this recently when a colleague lamented that on his new job, the QA lead assigned to his project did not believe that an obvious error in the software should be tracked as a bug in their issue tracker unless it was actually observed in production. The only way this mindset can be considered sane given proper software development practices is if you have a system that exists only in a production environment.
First, it is probably somewhat helpful to classify what I constitute as a bug. This is obviously up for debate, but I believe any seasoned software developer or software tester would include the following classifications of issues as a bug to be tracked:
- improperly implemented business logic
- common programmer errors such as bad/missing input validation, syntax errors on non-compiled languages
- incorrect packaging of build artifacts
- bad configuration as it relates to deployment, configuration management, or system administration
And, probably a slew of other things that do not come immediately to mind that cause software to not behave as its stakeholders intend.
If any of the above problems actually exists in a software codebase or perhaps in the code/configuration management/deployment system being used, then it behooves the development team to actually file these details as bugs in their issue tracking system so that the occurrence of the bug can be tracked and marked against a combination of the version of the software and environment that causes their existence. This further allows for the following:
- Documentation around what conditions causes the bug to manifest
- A centralized place for discussion about the bug that is easily referenced, searched, and is archived
- Links to how the bug was fixed, such as the commit id or revision in source control
- A common way to refer to the bug across all teams—the bug is referred to by a canonical identifier instead of by a conversational “that thing where User X doing Thing Y on Form Z causes thingamajigger W”
This makes it is easy for the development team to both write tests to prevent regression and to more quickly fix a regression by having an easily referenced source that describes the nature of the bug and what was originally done to fix it. It pays to err on the side of more tracking than less tracking when it comes to flaws in software—and anyone who is the gatekeeper of the quality of software should have the utmost concern for tracking a software project’s flaws and preventing their recurrence.
Published at DZone with permission of Jason Whaley , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.