The Bugs That Deceived Me


Yes they are. And still, these unmentioned bugs can contribute to the same analysis. These bugs have been a blind spot for me. As I test the whole application, I don’t see them, and I’m definitely not aware of what happened before the code entered source control.

Because this data is lost, we‘re left with the bugs in the database.

To tell the truth, I’ve decidedly let this one go. Collecting all this information requires more attention, more data collection.

Instead, we discuss the big picture in a qualitative manner. Luckily, I work with a small team, and we do ongoing analysis of bugs as part of retrospectives. Although not accurate, these discussions help us to identify and handle the risky parts of the code.

More Data, Better Analysis
As a developer, I never thought about grouping bugs. When I found them in my code before anyone else, I didn’t even call it a bug. When I “grew up” and adopted a more encompassing point of view, I look at them differently.

Bug information doesn’t live in a vacuum. In agile we talk about context and how it’s part of information.

With a bug, we’re interested not just with the bug description, but also where and when it was found, how and who did the analysis, etc. We can then group bugs together to point us at quality problems.

Every once in a while, it helps to take a look at the big picture, not just look at the bugs individually. Bugs are usually symptoms of ineffective processes.

How Do I Start?
Start with simple questions about bugs like “Where do they come in droves?” and “Where do they not frequently appear?” After doing so, make a decision about what to track and follow up.

Then continue to ask questions. It’s not like these bugs are going away, are they?

User Comments

1 comment
Rob Black's picture

Are you also doing a root cause analysis and tracking the results of such?  For example, is the defect caused by a missed unit test, changing requirements, missing requirement, misunderstood requirement, non implemented feature, architectural breakdown, etc.  Do you also track defects in documentation that take away from time spent on the core deliverable application?  I'm a firm believer that rework costs money.  And rework can be in many different software lifecycle artifacts.  For some applications, or projects, the supporting artifacts are of great value.  For instance if a team is to deliver an SDK, the supporting documentation is very valuable in reducing calls for support.  In other efforts, the supporting artifacts may aid in certification or regulatory approval.  Whether this be from internal audits, external government or customer audits, etc.  Quality is measured by the customers perceived value of a product.  Yet the cost of quality is measured internally.

January 6, 2014 - 7:27pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.