tag:blogger.com,1999:blog-7222462746492540485.post1224649885879886530..comments2024-03-12T18:29:48.203+00:00Comments on investigating software: Why so negative?Peter Houghtonhttp://www.blogger.com/profile/05100471888135365752noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7222462746492540485.post-37750595527057252642011-02-13T11:06:33.812+00:002011-02-13T11:06:33.812+00:00Thanks Michael, Thank you for your support - and y...Thanks Michael, Thank you for your support - and yes the RST course definitely helped motivate me! I recommend the course to testers, programmers and project managers!<br /><br />I agree with your main point - that the software is essentially broken before it reaches the tester. The tester finds out that these problems are present in the system, and reports them.<br /><br />1) In the blurb when I refer to breaking the software, I'm describing how the process appears to others. i.e.: "to a non-tester why you appear to be intent on breaking their..."<br />I tend not to use the phrase myself, except lightheartedly.<br /><br />2&3) I'm not so sure about these... for example: a judgement, coding or configuration mistake was made before the system is examined by the tester - But the system may not 'fail' until we perform certain actions. By fail I'm thinking: Displeases or confuses user, performs slowly, crashes or loses data etc.<br /><br />The incident on the Silver Bridge springs to mind (http://en.wikipedia.org/wiki/Silver_Bridge#Wreckage_analysis ) A contributing factor in the bridges 'failure' was a problem in the manufacture of a constituent part. Although this problem was in the system for many years, along with others such as a lack of redundancy, they did not 'fail' until December 15 1967.<br /><br />If we were testing such a system, might we not add higher than expected load in an attempt to 'cause a failure'?<br /><br />Though I can see that this engineering style language in a software setting is far from a perfect fit. Issues such as corrosion and decay don't apply. Though unplanned-for user load and change in usage do apply. I'm going to think about this...Peter Houghtonhttps://www.blogger.com/profile/05100471888135365752noreply@blogger.comtag:blogger.com,1999:blog-7222462746492540485.post-47872219521003186792011-02-12T23:02:53.787+00:002011-02-12T23:02:53.787+00:00It's an excellent point and a wonderful way of...It's an excellent point and a wonderful way of showing it, Pete. A few refinements:<br /><br />1) We don't break software; the software was broken when we got it.<br /><br />2) We don't create tests designed to cause failure; we create tests designed to <i>expose</i> the failures that are lurking.<br /><br />3) The illusion that the software wasn't broken and the illusion that we're creating failure are among the most important illusions we testers need to dispel.<br /><br />I'm delighted at the steady stream of excellent posts, and especially chuffed that it started to flow just after the Rapid Software Testing course in London. That was a rare group!<br /><br />---Michael B.Michael Bolton http://www.developsense.comhttps://www.blogger.com/profile/09027725699187903416noreply@blogger.com