Re: What defines a bug

[David E Jones]

-David


On Oct 28, 2007, at 11:28 AM, Jonathon -- Improov wrote:

For customers, yes, I think it's VERY important to make that distinction too. If you have a support contract or they want fixed bids it's critical. Even if not it is very valuable for planning and setting expectations, basically just good client communication.

Well, my message (or response) was very tied to the real world. My clients don't care what my design patterns or thoughts are. If something doesn't work according to their needs or wants, it's a bug.

Jonathon

David E Jones wrote:

I was trying to use the "gray areas" in my message to point out that a "design bug" (BJ's term?) may or may not be a bug in human perspective, depending on real world conditions (availability of resources, for eg). Of course, in IT speak and in a computer's perspective, a function that does not work as designed is buggy. But try telling that to a customer. "It's not a bug, it's a feature, so would you please?". :P

Was this message intended to evoke a response? Well, here it is.

-David
On Oct 28, 2007, at 12:32 AM, Jonathon -- Improov wrote:

The way I'm used to defining things what you describe is more of an "issue". An "issue" is anything that represents a difference between what a user (any user...) needs or wants and what the system offers. A bug is a totally different animal. When looking at bugs it doesn't matter at ALL what a user needs or wants, the only thing that matters is what the current system is designed to offer. If there is something that the system is designed to offer, or in other words that is already implemented in the system, but that is not functioning as intended, then THAT is a bug. Fixing a bug is changing something (usually small, isolated changes) that exists, not adding anything new. I may be biased on this one, but I don't really see this as all that complex. The point for any word is to have a useful definition that makes distinctions of value in real life. Defining a "bug" as anything a user doesn't like basically makes a release branch with "bug" fixes only useless, as it might as well be the trunk. That is a pretty good litmus test for this definition, IMO.

If some function doesn't work according to user needs, then it is a bug. Period.

Now the gray areas.





Jonathon

BJ Freeman wrote:

If that same function still serves the user's needs if used in some other ways (albeit not exactly according to user's mouse- clicking habits), it depends. If I'm given time and resources to fix the issue, then it is a bug. If I don't have time and resources to fix it, then it is... erm... not a bug. :P

Most bugs arise from mistakes and errors made by people in either a
program's source code or its design
we all accept that if the code breaks it is a bug.

So I put to you.
is it important to include how a user might use the application

interact without getting error messages.
if so is this considered a bug.

For applications that have UI, it is also a failure if the person using the application is not given the input necessary to put correct data and then gets an error message say they should. This to me is a design bug. inappropriately if there is not the correct information for the user

smime.p7s
Description: S/MIME cryptographic signature