I recently did a guest blog post about writing defect reports that include a value proposition; which is just another way of stating an impact of the defect. When writing the post, one thing occurred to me. The term defect is not exactly correct. Some are defects, some are misunderstandings, and some are suggestions. To add to the issue, Cem Kaner, recognized the legal implications of using the term defect (slide 23)
So, what exactly, should defects be called: bugs, defects, issues, problems, erratum, glitches, noncompliance items, software performance reports (spr), events, etc…? To understand what they should be called, we need to understand what “they” are.
What is an observation? There are many dictionary definitions, but for our discussion, let us use Merriam Webster’s third entry which is “an act of recognizing and noting a fact or occurrence often involving measurement with instruments”. The Free Dictionary Online has a similar definition of observation (second) as being “a detailed examination of something for analysis, diagnosis, or interpretation.” Isn’t that what we do as testers? We perform a series of actions to elicit a response and compare that response against a set of expectation? We then definitely log anything we consider as out of line with our expectations? I propose that is exactly what we do in the testing field. Therefore, defects are really observations. Perhaps we should start calling them so. It eliminates negative sounding words, eliminates legal concerns and, most of all, it better matches our actions. I propose we call them observations. Thoughts?
5 comments:
In the begining there were 'bugs', they were not considered to be a good thing. But they were real and present, and in mass numbers at times.
These bugs were 'defects' in the code or design of the system, and as such caused an 'issue' for the people both using the system and building it.
Thus if a bug was found an issue was raised by the users and they would point out the defect to the developers.
The developers would fix the defect so that is would no longer be an issue and as a result remove the bug from the system.
But in some instances the defect was found to acutally be an 'anomoly' caused by an 'inadequecy' in the original specification of the system.
This caused the system to naturally contain a defect that would eventually become an issue because it would just bug users because it was present.
Now because the inadequacy propogated the anomoly which led to the defect and caused an issue the end-users would just have to live with the bug.
Alas, the end-users complained and then management got involved. To smooth things over they proclaimed that the bug is not a defect and there was no longer an issue.
Instead they stated that the issue caused by the anomoly due to the inadequecy was actually a 'functionally unreproducible business application response', or FUBAR.
This FUBAR in turn would just make the 'system not available for use', or SNAFU.
This SNAFU was the real culprit behind the FUBAR and explained the inadequecy which removed the anomoly that raised the issue that was depicted by the defect which just bugged users.
This eventually led the users to believe that no matter what, a 'bug' will eventually lead to a FUBAR that causes a SNAFU.
Is there anything better then being able to say 'I found a bug!' or 'I found a defect!'. 'I observed this!' doesn't quite have the same ring to it. :-)
I believe it should be called whatever works for your organisation/project.
I would think though that whatever it was called, over time, it would become a negative sounding word, there would still be legal concerns and would be legal concerns with any word.
Tony,
I prefer to say I found something interesting. After all, is everything you find a bug or defect?
Joe, no not always a bug or defect, good point.
Perhaps a new word needs to be thought up.
Hi, Joseph...
Here's the way James Bach and I think of it and teach it.
Test execution has four steps--we configure, operate, observe, and evaluate the product. When we report, it's typically because our evaluation of a certain observation indicated a problem. Observations on their own, or observations that didn't result in a problem tend not to be so interesting (although they might be; for example, "nothing we observed suggested that there was a problem here".)
We think about two kinds of problems. A bug, for us, is (formally) something that threatens the value of the product. (Less formally, a bug is something that bugs someone who matters.) The second kind of problem is an issue. An issue is something that threatens the value of our testing. An issue might stem from a lack of information, the need for a certain tool that we don't have, a delay in obtaining a bit of code--anything that could compromise or slow down testing.
At one company where I did some training and consulting, they called bugs "issues", and they called issues "concerns". I thought that these were a little limp and anodyne, but to me it doesn't matter much; it worked for the client organization, so who am I to say? People are welcome, encouraged, to call things whatever they like (pace Cem Kaner's issue or concern with calling bugs defects).
Nice work here.
---Michael B.
Post a Comment