Skip navigation.

Bugs.... failures, faults and errors....

bug tracking/incident management
[textile]Bret Pettichord's blog entry "A bug is anything that bugs someone who matters":http://www.io.com/~wazmo/blog/archives/2004_09.html#000222 was of topical interest to me... I often lose time trying to explain to developers that when I log a test-failure in the 'incident tracking' system, there could be many causes. My test, test-code, environment and even the software under test could contain the fault or bug. What I love about Bret's post is the phrase "A bug is anything that bugs someone who matters"... that is often all we need developers and project managers to understand... Bombarding them with definitions with subtle variations is more than anyone else needs to know... it won't change how I conceptualise bugs in my mind...
**failure:** Deviation of the software from its expected delivery or service. **fault:** A manifestation of an error in software. A fault, if encountered may cause a failure. **error:** A human action that produces an incorrect result. From "testingstandards.co.uk/living_glossary.htm":http://testingstandards.co.uk/living_glossary.htm ... and defines **bug:** as "See fault"
...but it will change how I explain what a bug is to anyone for the first time... The reason I have decided to try this is because, despite everything I say, write or do - anything that goes into the 'Incident Tracking' tool seems to get interpreted by the developers as as a bug-in-the-software. The reaction is as though it is actually an attack on the 'goodness' of their creation... I have tried to explain to the developers that I log **"test-failures"** - not "bugs"... This just doesn't seem to be getting through... Perhaps by keeping it simple - in time, they will see for themselves that I am logging test-failures and some of them just happen to be diagnosed as bugs-in-their-code.