tag:blogger.com,1999:blog-8951904624959546499.post8353081014203780905..comments2008-07-29T13:26:30.429-04:00Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8951904624959546499.post-53495009728266596822008-07-29T13:26:00.000-04:002008-07-29T13:26:00.000-04:00Ido Schacham,<BR/><BR/>Great suggestion to talk to your tech support staff. I'll bet they would love to vent a little about user complaints. Understanding these complaints will give us insight to user expectations and help narrow future testing. I like it!Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-90472403666111734652008-07-29T09:41:00.000-04:002008-07-29T09:41:00.000-04:00Don't think there is a need to do any blaming, leave that kind of stuff for bad relationships. I agree with the superhero that you should learn from it, maybe improve your test beds to be more "real world" like. <BR/><BR/>However, that doesn't mean there won't be production bugs in the feature, there always will be as the software is just too complex with too many states and too much different hardware and other software versions to run it on that you just can't catch all the bugs. Not to mention we're all people, so some things slip our attention.<BR/><BR/>As James Bach says in one of his lectures, there are infinite tests. You just can't cover them all in a very short and finite time under the extreme pressure of the CEO who wants the testing to end and the software out now :)<BR/><BR/>To more practical advice - when I used to do QA full time I would show my test designs to my team leader, the developers in charge of the features, and usually another member of the QA department. Sometimes they actually read them and gave me feedback about the tests, that decreases the chance of missing something important. I also tried to be in touch with tech support to be aware of what kind of problems the customers are running into and what configurations they are using. Trying to run the same stuff they are running would help to make sure the important tests pass in the right environments.<BR/><BR/>HTH!Ido Schachamhttp://www.testuff.com/blognoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-89220899694103731492008-06-03T12:25:00.000-04:002008-06-03T12:25:00.000-04:00Thanks for the comment, Purple Crayon Superhero.<BR/><BR/>I like your advice to learn from the bugs found in the wild. Sometimes testers do a poor job of predicting the way software will be used, and they miss important tests.Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-26391924710072188002008-06-02T21:50:00.000-04:002008-06-02T21:50:00.000-04:00I wouldn't blame yourself. It's impossible to catch every single problem. Bugs are going to happen regardless.<BR/><BR/>As far as % responsibility I think it's more like 90% the developer's fault and 10% is due to testers/BL/BA/CEO/shareholders/George Bush/Beyonce/50 Cent/etc. And I'm sure most end users have heard of testers but ultimately the fault does indeed fall on the developer's shoulders. We wrote the code and it didn't perform as intended. <BR/><BR/>I don't know what the bug or problem was, but I think the important thing is instead of griping and being angry is to figure out what can we learn from it. Whenever there's a major problem and after it's resolved I do a post-mortem analysis and think of how we could've prevented it in the first place. Is there something I should've thought of doing or tested to avert this problem? Is there a pattern I can derive and apply to future problems like this? etc.purple crayon superheronoreply@blogger.com