Do not register bugs, Fix them!
For years I was a proponent of bug/issue management systems and worked with open systems like Jira or Bugzilla and also with a lot of proprietary systems. Iâ€™ve used these systems during the development and production/ support phase of the products. Every time I use these systems I spend too much time registering, evaluating and sorting issues. At the end of the project I always get stuck with a dozen of unspecified issues with a vague status. Why is this? Bug tracking systems are not bad. The entire process of registering and tracking bugs is wrong.
What the most effective thing to do when you discover a bug? Registered the bug in a system and track it? Does this solve the bug? It doesnâ€™t. Â You should be busy resolving the bug, not administrating and tacking it!
Why should you register bugs during a project? Why not fix them. The bug is discovered and immediately handed over to the developer who is able to fix it quickly and pass it over to the tester. This is of course easier in a co-located agile team than in a team with a formal testing department, handovers and sign-offs. This issue resolution process can take place in a matter of minutes, discussion about the nature and resolution options can be done directly. Â Complete cycle without any form of registration.Â With registration this process would take more time and discussion. Nobody looks at the list of resolved issues. When the issue is resolved the issue information is of no value at all.
Why do we register bugs?
- To prove you have tested the application? No, use the test scripts and test reports for this. When you have to prove testing by handing over the list of resolved issues you have serious trust issues with your customer.
- To prove quality of the application? No, the number of issues does not prove anything. Are these all issues? Are all issues found? Or is there just one blocking issue that is not discovered yet?
- To prove you are productive? No, issue resolution is not an indicator of productivity. It is an indicator of being busy. Â Valuable functionality is the measure of productivity.
- To remember the issue for later resolution? No, when the issue resolution can wait is not important and you do not have to register it. This is not an issue but a feature request.
- To conserve a resolution for future usage? No, log the resolution in a user manual or in the (technical) documentation.
- To create release notes? No, release notes should contain a list of new or changed functionality and instructions for usage. Not a list of resolved issues. The readers of the release notes are not interested in specific bugs. They want to know if the new functionality is included. They expect issues from the previous release to be resolved.
Still no reason for registering bugs. .
An issue management system is a perfect system for hiding and losing your issues. The bugs are â€œin the systemâ€ and with the right account, access rights, filters and select criteria the issue manager is able to generate a list of the current issues. But you are not sure about the actual number of issues because the issues are â€œlinked: resolved-inâ€, duplicated or contain sub-issues. The systems surely produce absolute numbers but are these really current and important issues? Â Issues change during the storage in the issue management system. During storage of issues in the system the issues become less important, less clear or irrelevant due to external factors (other solutions, changed applications, new suppliers or lost customers).
Bug registration is actually blocking the full value of your product.
The issue manager with a bug management system will frequently review and evaluate all bugs and assess their priority.
Firstly, the time spend on evaluating bugs is not spend on resolving them or on creating valuable functionality in your product.
Secondly, each bug is representing a concrete value. When the bug is resolved the feature / functionality with this issue becomes more valuable. When you do not resolve this bug you are holding back some (or a lot) of the value on your application. Not all bugs are immediately invaluable. But their â€œresolution-valueâ€ diminishes in time. Users will find a work around or just chose to use another application.
Thirdly, the resolution time of an issue/bug grows exponentially over time. When the bug is discovered in code created some hours ago the developer has still the code in mind and can resolve this quickly. When the resolution starts weeks after discovery the developer is thinking about another piece of code or (even better for him) is on vacation.Â Resolution will take a lot longer.
When you discover an issue, just fix it and do not spend time on mindless registration. When you need a reminder use a bright colored post-it memo and stick it on the concerning feature (or preferably on the forehead of the concerning developer).
Creating working software is fun, issue administration isnâ€™t.
- How to write a good incident description/file a clear bug report
- Good Citizenship – Have Client Applications register themselves with the database
- Agile software development, the principles. Principle 7: Working software is the primary measure of progress.
- Agile software development, the principles. Principle 3: Deliver working software frequently
- Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Case Study: A Case of Fusion Middleware
- Kom kennismaken met AMIS en doe mee met uitdagende projecten
- Uitnodiging: Kom kennismaken met AMIS
- JDeveloper – Conditional Breakpoints saving time and a lot of clicking (IDE tip)
- KSCOPE 2011: What do you mean â€œAgileâ€?
- Compliments; Instant productivity improvement for software teams, with a small effort….
- ADF 11g: Debugging Task Flows embedded from ADF Libraries using source code jars
- Automatic testing Oracle Service Bus using Hudson, maven and SoapUI
- Agile software development, the principles. Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
- Agile software development, the principles. Principle 10: Simplicity -“the art of maximizing the amount of work not done“- is essential