According to Joel Spolsky (a.k.a. Joel on Software), “keeping a database of bugs is one of the hallmarks of a good software team.” However, it’s amazing how few software shops fully utilize this strategy yet tout the importance of software quality control. Bug tracking is the process of finding defects in a product and making new versions of that product that fix the defects. Bug tracking is important as complex software systems typically have numerous bugs so managing, evaluating, and prioritizing bugs is a difficult task.
What Constitutes a Bug?
Before you can track software bugs, let’s define what exactly constitutes a software bug. Examples of obvious software bugs are when an application crashes or displays the dreaded “404 Not Found” web page. Clearly, these are bugs, but what about other problems such as pages that are not visually appealing, are missing data, or are displaying the wrong content? Anything that requires someone on the team to make a change to the software product should be considered a bug, whether that means a change to the code, a cascading style sheet, or the content management system.
What is Software Quality Control?
The Quality Control (QC) team tests software to ensure quality through verification and validation. Verification and validation assures that a software system meets a user’s needs. Verification answers the question: “Are we building the product correctly?” The software should conform to its specification. On the other hand, validation answers the question: “Are we building the right product?” and when to verify. If a test fails and can be duplicated, a bug is reported.
Why Track Bugs That Don’t Require a Change to the Code?
Communication between teams is greatly enhanced by the simple task of tracking software bugs. How else does your QC team know why their tests are broken? Once a bug is fixed, then QC knows to re-run their test to confirm that the bug is actually fixed. Furthermore, documenting software bugs provides an invaluable historical record.
OK, so now what? How do you avoid getting bogged down by the task of tracking bugs? Simplification! First, use a database to log your bugs, preferably backed with a simple bug flow process. There are oodles of bug tracking databases you can buy. Here at Segue, we use Seapine’s Test Track which tracks defects, feature requests, change requests, tasks, and more. Once you have a bug tracking process in place, ensure that all your teams consistently follow that process.
Three Parts to Every Good Bug Report
It’s pretty easy to remember the rule for a good bug report. Every bug report needs exactly three things:
- Steps to reproduce
- The expected results
- The actual results
For more information on bug reports, read “How to Effectively Report Software Defects” by Quality Control Manager LaTonya Pearson.
Bug Resolutions
Once a bug is fixed, a tester verifies the fix by following the steps to reproduce the bug. If the actual results now match the expected results, then the test passes and the bug report can be closed. Otherwise, the bug report is reopened
Joel also says, “Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.” At Segue, we’ve found that while the time invested in bug tracking is minimal, the benefits of improved software quality control and communication among teams is greatly improved.