tag:blogger.com,1999:blog-8253356399910042383.post3567761826644000748..comments2018-04-07T00:47:47.789-04:00Comments on Joseph Ours' Blog: Redefining DefectsAnonymoushttp://www.blogger.com/profile/06611114224806937222noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8253356399910042383.post-13541621503594194932009-07-18T18:22:04.297-04:002009-07-18T18:22:04.297-04:00Hi, Joseph...
Here's the way James Bach and I...Hi, Joseph...<br /><br />Here's the way James Bach and I think of it and teach it.<br /><br />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".)<br /><br />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.<br /><br />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 (<i>pace</i> Cem Kaner's issue or concern with calling bugs defects).<br /><br />Nice work here.<br /><br />---Michael B.Michael Bolton http://www.developsense.comhttps://www.blogger.com/profile/09027725699187903416noreply@blogger.comtag:blogger.com,1999:blog-8253356399910042383.post-33364456327372119092009-07-08T16:16:51.031-04:002009-07-08T16:16:51.031-04:00Joe, no not always a bug or defect, good point.
P...Joe, no not always a bug or defect, good point.<br /><br />Perhaps a new word needs to be thought up.Tony Brucehttps://www.blogger.com/profile/14044205740382054059noreply@blogger.comtag:blogger.com,1999:blog-8253356399910042383.post-16439001414775891282009-07-07T09:30:42.348-04:002009-07-07T09:30:42.348-04:00Tony,
I prefer to say I found something interesti...Tony,<br /><br />I prefer to say I found something interesting. After all, is everything you find a bug or defect?Joseph Ourshttps://www.blogger.com/profile/02348622905292995836noreply@blogger.comtag:blogger.com,1999:blog-8253356399910042383.post-27075863165319742662009-07-07T08:54:38.385-04:002009-07-07T08:54:38.385-04:00Is there anything better then being able to say &#...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. :-)<br />I believe it should be called whatever works for your organisation/project.<br />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 Brucehttps://www.blogger.com/profile/14044205740382054059noreply@blogger.comtag:blogger.com,1999:blog-8253356399910042383.post-69362921860410430492009-07-06T19:01:31.563-04:002009-07-06T19:01:31.563-04:00In the begining there were 'bugs', they we...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.<br />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.<br />Thus if a bug was found an issue was raised by the users and they would point out the defect to the developers.<br />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.<br />But in some instances the defect was found to acutally be an 'anomoly' caused by an 'inadequecy' in the original specification of the system.<br />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.<br /><br />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.<br />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.<br />Instead they stated that the issue caused by the anomoly due to the inadequecy was actually a 'functionally unreproducible business application response', or FUBAR.<br />This FUBAR in turn would just make the 'system not available for use', or SNAFU.<br />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.<br /><br />This eventually led the users to believe that no matter what, a 'bug' will eventually lead to a FUBAR that causes a SNAFU.Calkelpdivernoreply@blogger.com