tag:blogger.com,1999:blog-9421494.post7120471256642394973..comments2024-03-27T06:18:38.214-04:00Comments on Lessons Learned by a Software Tester: Testers Create Bugs, Not Bug Reports!Paulhttp://www.blogger.com/profile/16826575269870573990noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-9421494.post-26345460454311331982009-01-24T13:38:00.000-05:002009-01-24T13:38:00.000-05:00Hello ibeta. Thanks for your comment.ibeta wrote:...Hello ibeta. Thanks for your comment.<BR/><BR/>ibeta wrote:<BR/><I>"Instead of asking yourself "If a tree fell in the forest, does it make a sound?", ask "What caused the tree to fall in the first place?""</I><BR/><BR/>I can't answer that! That's a "Quality Assurance" question, not a "Software Tester" one! ;)<BR/><BR/>I take a passing interest in what the cause is, but that wasn't the point of my original post. I think following that line of thinking will lead to a whole new set of ideas... :)<BR/><BR/>Cheers! P.Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-52453205185782165422009-01-21T12:00:00.000-05:002009-01-21T12:00:00.000-05:00I think your first question you should ask yoursel...I think your first question you should ask yourself is "what is a bug"? Ask, your co-workers what their definition of a "Bug" is, and just listen. You have your opinion of what a "Bug" is, you can even surf the web for many opinions on the definition of a "Bug". I think this is the key question that needs to be asked before any arguments can be valid for either side. I know my definition of a "Bug", and from that this is my opinion, in fact I do not call them "Bugs", I call them issues, because I am reporting what I observe. It may, or may not be a "bug" in the software, my observed result may be what was supposed to happen. It may not even be the projects software that is causing the issue, it could be settings or a specific setup I have on my test machine.<BR/>Testers most definitely do create bugs though , but not always. In fact both points have truth. But a piece of software always has a scope. It is always developed to some general standards, sometimes very strict standards. The question the tester asks is, "is this issue within the scope of the project?". There is far to much hardware in the world to make a piece of software run perfectly on everything. Do you happen to possess the correct setup to see an issue that 99.99% of other users may not. Sure you can change your perspective on how to use the software not intended by the developers, which would obviously create issues. In this regard yes, testers do create bugs, this is especially seen in game testing. Using the tools given in a game environment, testers will always do things not even though of by the developers.<BR/>On the flip side, developers also make bugs. Of course they are not intentional, its not as though they woke up in the morning and said, ok I am going to place 9 bugs in my snippet of code today. We are only human, we make mistakes. No matter how good the developer thinks they are, they still make mistakes. The larger and more complex the code has to be, the more accidental issues are likely to be introduced. Then there is the merging of snippets of code. No two people code the same, so when multiple people merge code it is up to a few coders to get all of those snippets of code working together. This can be just as hard as getting people to work together. <BR/>Instead of asking yourself "If a tree fell in the forest, does it make a sound?", ask "What caused the tree to fall in the first place?".ibeta Jollygreenghttps://www.blogger.com/profile/03811877806365416815noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-53404409770731638902008-08-06T06:02:00.000-04:002008-08-06T06:02:00.000-04:00"if a tree falls in the forest and no one is aroun...<I>"if a tree falls in the forest and no one is around to hear it, does it make a sound?" </I><BR/><BR/>Oh, it did make sound. I was there but maybe no one could see me from far enough distance or through imaging systems because it was a dense forest.<BR/><BR/>It was so dense that I heard a "THUD" near me and when I turned, I saw a tree lying. I conjecture from what I see and heard that it could be a tree that caused the "THUD".<BR/><BR/>I see a bug and create a story of the bug. I am a character in that story. I came in when too many things were happening. As a human, I was unable to notice all things that were happening so I conjecture from what I see, hear and feel that this is what could have happened.<BR/><BR/><I>One might argue, then, that if you make the bug reports go away you make the bugs go away. If no one (customer) sees the bug, does it really exist?</I><BR/><BR/>If no one to our knowledge see a bug and report them or talk about it near our ears, we don't hear about the bug. Hence we spend our time on things that we have heard ( because there might be too many things we heard or suspect ).<BR/><BR/>Not many people might click "Send Report" whenever a Microsoft Application or OS crashes. So, if I were sitting in the team that receives all this report and I see only three people having accepted to send a report for MS Word crash think "It just crashed thrice out of millions of customers"?<BR/><BR/>We ( as customers ) ignore bugs sometimes ( unless it bothers us too much ). We ( as testers ) are bothered about customers being bothered.<BR/><BR/>We ( testers ) don't know or have little information about what might bother a customer and try flushing out as many bugs as possible.<BR/><BR/>This forms a vital information about the quality of the product.Pradeep Soundararajanhttps://www.blogger.com/profile/17849721523107325938noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-12427925260843441012008-05-09T08:45:00.000-04:002008-05-09T08:45:00.000-04:00Hmmm, ... I don't know, I won't say you are wrong,...Hmmm, ... I don't know, I won't say you are wrong, it's just your way of looking at things. To me it seems more like the case of the person who is used to drive through a certain course and one day he just seats on the passenger seat and is driven instead. He then goes "oh my, that's such a lovely scenery. I had never noticed it before". But the scenery was there all along.<BR/><BR/>I do agree with you when you say that requirements will never be perfect.<BR/><BR/>Anyway, it was fine chatting with you. I'll probably visit more often. Have fun!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9421494.post-90188043488935392012008-05-08T23:27:00.000-04:002008-05-08T23:27:00.000-04:00Hello Paulo, thank you for your reply. Part of me...Hello Paulo, thank you for your reply. Part of me agrees with almost everything you've said.<BR/><BR/>Part of me is still thinking about the main idea I was trying to get across in my original post, though.<BR/><BR/>First: the tree falling. I studied Physics in school and my initial thought is to agree with both you and Wikipedia. However, that only represents one, <I>Scientific</I>, perspective, and not necessarily the same perspective that everyone else will have. The purpose of this example is because (I believe) it is a non-software example of the same idea I'm trying to get across in the rest of the post.<BR/><BR/>To illustrate my point here, don't debate with me in a blog about it (because that won't probably be as much fun as the alternative..). Ask your friends or family that question the next time you see them and see what <I>they</I> think. Don't give your answer first. Just listen to their opinions. Instead of correcting anyone's opinions, just ask them <I>why</I> they think that way. The question can always be answered easily when you only have one opinion to consider -- your own. Not everyone will necessarily agree with Wikipedia either.<BR/><BR/>Next, regarding your 3 possible answers to the remaining issue of who creates a software bug. I will divide your answers into 2 categories: (a) the programmer made a mistake of some kind, and (b) there was a misinterpretation in or of the requirements somewhere.<BR/><BR/>The first one, (a), is trivial I think. I agree with you that it is the programmer's bug and you are simply helping them realise it. Out of curiosity, do you know roughly what percentage of your overall bug count this represents? (BTW, I don't know the answer. I think the answer might change for every project, although it might be an interesting question to try and answer.) Based on my experience, for the projects that I have worked on over the last decade, these bugs <B>don't</B> represent > 50% of all the bugs reported on a project. So they are not the majority of the bugs found on the projects that I have participated in.<BR/><BR/>As for the (b) responses, I think all requirements are vague, ambiguous or incomplete in some way to some person. That's just the nature of requirements. I don't believe it's possible, or economically prudent to invest the time and energy, to make them 'perfect' (i.e. correct, unmistakable and clear to all readers).<BR/><BR/>So if requirements are always vague in some way, it comes down to interpretation by the reader. As a tester, we change our interpretations by wearing different 'hats'. This is otherwise known as applying different test techniques.<BR/><BR/>Here's the important part: the requirements don't change; the code doesn't change; the bugs appear because your <I>perspective</I> on them changes. You change your frame of reference and you see things in a different way. Sometimes this leads to more bugs; sometimes it doesn't.<BR/><BR/>This is an important part of what we do as Software Testers. We change our perspectives. We change our frame of references. And to get bugs fixed, we try to change the opinions/minds of those who matter to see these new perspectives as important enough to be worth spending time, money and effort to 'fix' them.<BR/><BR/>One might argue that these 'bugs' already exist in the 'solution' or 'product' (by which I am referring to more than just the software -- include the whole system and requirements too). So, in that case, we <B>don't</B> create the bugs.. they're already present.<BR/><BR/>Perhaps. That's one perspective.<BR/><BR/>We change our perspectives because we <I>believe</I> that the perspectives are valid when we find a bug. Are all bugs valid though? That is, do they always represent a valid perspective of someone who matters to the development of the project?<BR/><BR/>Are they still bugs if the perspectives are not correct for a given project?<BR/><BR/>I leave it to you to think about it.<BR/><BR/>Thanks again for your terrific reply!<BR/><BR/>Ciao! Paulo. =)Paulhttps://www.blogger.com/profile/16826575269870573990noreply@blogger.comtag:blogger.com,1999:blog-9421494.post-86978694591854485632008-05-08T12:01:00.000-04:002008-05-08T12:01:00.000-04:00Hi Paul. How have you been? Ok? Great.I was readin...Hi Paul. How have you been? Ok? Great.<BR/><BR/>I was reading your interesting text about testers creating bugs. First of all I think we should clear that tree falling in the forest issue. According to the wikipedia a sound "is vibration transmitted through an elastic solid, liquid or gas, composed of frequencies capable of being detected by organs of hearing.". This means that, unless the laws of physics change, if the tree falls there will be sound.<BR/><BR/>Ok, so now that we cleared that one, we can move on to the "testers creating bugs" issue. There is no doubt in my mind that testers absolutely do not create bugs. Unless they sabotage the code or the requirements, or they are acting in bad faith effectively calling something a defect when it is not. Or maybe the tester plain and simply understood it wrong. That happens too.<BR/><BR/>In your example you say that the programmer interpreted the requirements in some way. And apparently that was not the correct way. There are several reasons for this.<BR/><BR/>1. The requirement was ambiguous or incomplete. If this is the case, then there is a defect in the requirement. It should be removed from the requirement and the code corrected accordingly.<BR/><BR/>2. The requirement is fine, and the programmer misread it. Tough, there's a defect in the code. Correct the code.<BR/><BR/>3. The business specialist didn't explain himself correctly or the analyst didn't understand him. Defect in the requirements, follow recipe in 1.<BR/><BR/>Can't really see how was it that suddenly the tester created a bug.<BR/><BR/>Cheers<BR/><BR/>PauloAnonymousnoreply@blogger.com