tag:blogger.com,1999:blog-8951904624959546499.post1613548395852735829..comments2008-04-02T13:30:54.810-04:00Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8951904624959546499.post-31751574995138917922008-04-02T13:30:00.000-04:002008-04-02T13:30:00.000-04:00Yes, I agree, a good tester should do that. But only to an extent. Even after eliminating possible causes the devs still sometimes shrug and say "it's not my code". And it is difficult for the tester to convince them otherwise.<BR/><BR/>I don't think it's unreasonable to ask the devs to walk over to each other's cube and figure it out sometimes. In fact, I'm embarrassed for them if they have not done this prior to giving me something testable.Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-40963273382109502852008-04-02T10:20:00.000-04:002008-04-02T10:20:00.000-04:00A good tester is a trouble shooter. By trouble-shooting, you should eliminate possible causes of a bug in one module and then do the same with another module. As a dev, I would not want to debug other dev's problem if I don't have to. It's just too time-consuming and makes me look like an idiot when I don't know well about another module (so many stupid questions to ask just to set up test data). I assume you were talking about a complex system. Hence, test data is hard to set up. Otherwise, you wouldn't have this problem of figuring out which module is buggy.Anonymousnoreply@blogger.com