tag:blogger.com,1999:blog-8951904624959546499.post7797218210383688095..comments2024-02-22T05:36:59.121-05:00Comments on Test This Blog - Eric Jacobson's Software Testing Blog: Don’t Find Bugs, Prevent BugsEric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8951904624959546499.post-32649434413763755282014-05-23T14:12:34.816-04:002014-05-23T14:12:34.816-04:00I'm not trying to knock a good post - I liked ...I'm not trying to knock a good post - I liked your blog. But I really think you are just pointing out the obvious. Having testers create bugs based on scenarios for code not yet created will definitely help the developer because he/she can make sure that their code accounts for those scenarios. That makes perfect sense. And that is really why there is a need for thorough requirements before a developer starts to code.<br /><br />In today's environment where documented requirements seem to be falling by the wayside, developers more and more are relying on the testers to guide them. To me, that is what the point of your post is although it's not really said that way. I would correct that problem by not putting the burden on the tester to create scenarios for the developer but would instead make sure that the developer had thorough requirements.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-51865569878598741802013-05-20T13:28:57.584-04:002013-05-20T13:28:57.584-04:00"There is tremendous benefit to the programme..."There is tremendous benefit to the programmer knowing about these UI bugs while the programmer is writing the UI initially. Thus, why not have our testers begin performing exploratory testing before the Story is code complete?"<br /><br />Why aren't programmers doing this?<br /><br />In my world I see programmers making the same mistakes over and over again. I've brought these issues to the attention of the programmer and management and yet nothing ever changes. I know this is the reality for a lot of testers.<br /><br />How do testers train programmers and management to wake up and stop this?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-70662294857823998092013-05-20T03:09:30.589-04:002013-05-20T03:09:30.589-04:00Nice post, Eric. That's exactly what other ind...Nice post, Eric. That's exactly what other industries have done for quite some time. <br />I think that is one way to go to be able to catch apparent stuff before it gets into the development.<br />Another way is to "help" the users to not being able to work wrongly. It's no magic, but its a small step towards a more smart and efficient way of working instead of looking for errors after the work has been done. Ronaldhttps://www.blogger.com/profile/07858025177950125728noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-33777104954158407502013-05-17T16:11:47.908-04:002013-05-17T16:11:47.908-04:00Anonymous, good point. It sounds like you are sayi...Anonymous, good point. It sounds like you are saying, no matter how early you test, additional changes can not be prevented. I agree. People don't know what they want until they start using it, right?<br /><br />However, change/creep is not what I am talking about. I would argue, change/creep bugs are not the kind of bugs testers attempt to find. Change/creep bugs, by definition, normally can not be found until the product is released.<br /><br />In this post, I'm suggesting (and I think Cheezy is suggesting) bugs that would otherwise be coded then hunted for, could possibly be prevented from existing in even the first build of the product.<br /><br />See the difference?Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-52133926672932525392013-05-17T14:49:18.791-04:002013-05-17T14:49:18.791-04:00As wonderful as your observation sounds, in the cu...As wonderful as your observation sounds, in the current software environment (especially with highly diverse and globally located teams) bugs are almost a certainty. And in my experience, most UI bugs are (for lack of a better term) superficial (labels, placement, colors, graphics, etc.) and not functional (the user cannot select the yes radio button, the address validation is failing, etc). And where there are "functional" bugs, they are more the result of requirement change/creep than poor development.Anonymousnoreply@blogger.com