Actually what is a bug ? any predefined rules?
A bug is:
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. (From Wikipedia)
Here is another good definition of what constitutes a bug. Either:
- The program did not behave according to the programmer’s intentions. or
- The programmer’s intentions did not fulfill common and reasonable user expectations.
Ubuntu community has a excellent definition for bug in this wiki, especially highlighting the difference between bug and missing features:
A software bug is an error or fault in a computer program which makes it fail to work as it's supposed to. This could be as simple as failing to work at all, or as complicated as a subtly incorrect result [...] Some things aren't bugs, but are missing features that should be reasonably included. Missing features shouldn't be reported as bugs, instead FeatureSpecifications should be written for them.
While it is hard to draw a line separating the two definitions and answer the question is it bugs or missing features?, it is possible to give some guidelines:
- if it's a problem that would have many details to address, it's likely to be a feature. For example, the inability to write files safely to a modern Windows partition is a missing feature.
- The inability to write files safely to a ReiserFS partition would be a bug.
The difference between the two assertions is: the first is more widespread (support modern windows FS) and thus can be view as Missing Feature, while the other emphasizes a unique problem (can't write into ReiserFS) - a specific bug.
If you are interested, I recommends you to take a look at the BugSquad team wiki. Fighting bugs is one of the most interesting activities involved in software development cycle, besides being a great learning opportunity :-)
I'll take a swing. Primarily, behaviour not intended by the designer / programmer (discounting bad design). In terms of what bugs you should report to people, anything which makes the program hrder to use and fits the above description. This includes, from worst to least severe, system crashes, X crashes, program crashes and any internal program bugs.
Bugs which cause crashes or window closures will usually cause some kind of output to stderror if you've run the application from a terminal, this can be useful. Also see system logs for error reports.
For all practical purposes the term "bug" should be avoided as a too fuzzy term.
The best answer to your question fills a whole book: "Why Programs Fail" by Andreas Zeller. A book that should be on every programmers' bookshelf. The author also makes a good effort in not calling them "bugs" (read on). Because as crncosta's answer already suggests a "bug" isn't just a programming error. This is why some people prefer the term "issue" instead (which leads to "issue tracker" instead of "bug tracker").
Because what's perceived as a bug by an end-user needn't be a bug at all. It can be - even though this is often used as a lame excuse - simply by design. Some failures however, once observed, are classified "bugs", even though they are due to lack of a feature.
The author of aforementioned book spends several pages on the definition of terms such as failure and defect and describing why "bug" is not an appropriate term (too fuzzy).
Summary of his terminology:
- programmer creates the defect
- defect causes an infection ("faulty program state")
- infection propagates
- infection causes failure ("observable bad/unintended behavior")
- observer (usually the end-user) sees the failure
As you can see the author distinguishes between cause and effect, which in the case of "bug" is almost always mixed. Most of the time the term "bug" is being applied to the defect, the infection and the failure.