January 14th, 2008

You Are Creating Bugs In Your Software

bug killer

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

One way to identify the sources of bugs is by listening to how people tell you about the bugs.

“That is not what I want”
“That is not what I said”
“That is not what I meant”
“That is not how it is supposed to work”
“That is not what they meant”
“That is not what I want it to do”

Visually, you can think of the development process (regardless of methodology) like the following flow

where bugs enter the process

Each of the six sources of bugs is labeled in the above flow. The article, Where Bugs Come From, goes into a detailed explanation of each source of bugs. This article looks at what you can do to improve the ability of your process to reduce these bugs. I have been a stakeholder, a product manager, a business analyst, a developer and a tester. And I’ve been guilty of all of these offenses at one time or another. When I say you, I also mean me. So chill.

“That is not what I want”

Stakeholders introduce bugs into the process by being unable to define what they want. Some agile methodology proponents argue that as a stakeholder, you can’t know what you want until you have something you don’t want in front of you. In other words, those agilists are giving up on trying to prevent these errors - they claim it is futile.

You can change your mind. The team could be dealing with “That is not what I want now” - and change is something that can not be prevented - although the impact of change can be mitigated. Iterative development and course-correction through getting immediate feedback is one way to do that. Prototyping is another method of course correction. Prototypes can also be used to elicit implicit requirements.

But that still avoids trying to directly address the issue of you not effectively describing what you actually want. There are ways to improve your team’s engagement with you, so that you actually say what you want. First, an emphasis on valuable requirements drives critical thinking about why you need a particular capability or feature. One approach to achieve valuable requirements is to question their justification.

The key to making this work is to make sure you are approving your requirements. And watch out for the anti-patterns in the article.

“That is not what I said”

Business analysts, product managers, and requirements analysts introduce bugs into the process through misunderstanding the stakeholders. Using the techniques above to stay on top of changes in stakeholder needs is not enough. Even when you effectively engage your stakeholders so that they are self-aware and can articulate exactly what they need and why, you still have a problem.

You can improve how you listen, and you can improve how you document what you heard. Make sure that you write complete, consistent and unambiguous requirements. While you’re at it - make sure you are writing your requirements correctly.

“That is not what I meant”

Developers can misinterpret requirements. While there are situations where a requirement is adequately expressed, but the developer is not capable of understanding, that is not the norm. Developers are smart. The onus is on the person writing requirements to make sure that they are written for the audience. So, even though the source of these bugs appears to be the developers, it is actually your documentation. If your documents need to span cultural chasms, then that’s your reality.

Make sure you write your requirements unambiguously, so that they are not misinterpreted. Make sure that they are feasible requirements, and that they do not specify design. The requirements also need to be concise without being overly terse.

“That is not how it is supposed to work”"

Developers should test what they create. Given an understanding of what you believe the code is supposed to do, you should test that it actually does it. This is the stereotypical bug - we asked for X, and it doesn’t work. Continuous integration is the most effective technique for addressing bugs that are introduced at this point in the process.

In more complex situations, you can apply more advanced techniques to assure that your testing is complete.

“That is not what they meant”

The testing team can also misinterpret requirements. This is a source of false positive bugs - even when the developers properly interpret the requirements, a bug may be lodged against their code when there is no bug. That’s why we have the ability to mark issues as “not a bug” when closing them. Apply the same rules for well-written requirements and you will also address this issue. Further, make sure that your requirements can be measurable, or verifiable. We recently wrote more about why you should make requirements testable.

“That is not what I want it to do”

User education is the key here. Users should be encouraged to provide feedback about your product. You don’t want to discourage feedback, you want to minimize the number of false positives. False positives come from users misinterpreting how the application is behaving - a sign of poor design. False positives also come from users not understanding what the application can (or should) do.

You can address design issues by focusing on design with the user in mind. And you can educate the users through a combination of training and with a novel approach to documentation. Document the product in terms of what users are trying to accomplish, in the context of how they are trying to do it.

Conclusion

There are a lot of people involved in the software development lifecycle. As people, we introduce bugs. As informed software professionals, we also know how to address many of them.

Please Rate This Article!