The Bugs That Deceived Me

[article]

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

Gil Zilberfeld's picture Gil Zilberfeld

Gil is the product manager at Typemock, working as part of an agile team in an agile company, creating tools for agile developers. He promotes unit testing and other design practices, down-to-earth agile methods, and some incredibly cool tools. Gil speaks in local and international venues about unit testing, TDD, and agile practices and communication. And in his spare time he shoots zombies, for fun.

Gil blogs at www.gilzilberfeld.com on different agile topics, including processes, communication and unit testing.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09