e-Talk Radio: Pettichord, Bret, 8 February 2001

[article]

he is not going to care so much from the width of the kind of scope. This makes these two entities, if I may say, very complementary to each other. But the main key point here is that both of them and the whole organization has to believe that they are on a completely equal basis. And that there are not such things as the developers are better or worse than the testers and the other side too.

Carol: Okay. Thank you for -

Caller: I believe from my experience that most of the organizations here, they pay more attention to the developers and not even anything, they do not even pay attention at all to the testers. This is where the problem starts.

Carol: That very well may be true. It may come through in salary as well, that developers may get paid more than testers.

Caller: Right. I believe personally that the developers, a software person, a software that I call developer tested, it has to be in his career or her career a kind of going back and forth to the two sides of the coin. Because, in order to be a good tester, you have to know how to code pretty well.

Bret: I think that is a good point. I have worked with a lot of teams where when a product is in development, the testing staff tends to be the most expert at what the product actually does and how it works. Many of the developers, like you said, have to go in deep. The system is decomposed and each developer is given a different module to work on, and they know how their module works real well. They have some interfaces to the other pieces, but they do not really understand the whole flow through the system. The testers are really the people who understand that the most. They have tried it many times and they can really see projects where they are the ones doing demos or where they are showing people how it works or what not. And even sometimes they are training the new developers because they are the ones who really understand how the whole system is put together.

Caller: Right. May I add something here?

Carol: Sure.

Caller: I believe that the testers, they have to be involved with the whole process from the very beginning. They have to participate in all the kinds of designs reviews, because they can input their own point of view that will prevent a lot of bugs, if I may say.

Bret: I think that there is a lot that testers can add when they come in early on a project. I have had testers who have found problems in different design documents up front which often, in my opinion, have prevented problems from showing up in the code later.

Carol: Excellent. I think that is excellent insight in terms of equal footing in saying that testers need to be involved up front. Maybe we can avoid some of the problems at the end of the lifecycle that we see right now which is kind of an antagonistic attitude towards each other. So, Alex, I would like to thank you for calling in. We have a second caller. You are on the air.

Caller: Hi Carol, my name is Greg.

Carol: Hi Greg.

Caller: I have a quick question for you and Bret. I do Web development so I kind of come at things from the developer angle. I was just wondering who you think would be the logical choice to be

About the author

Bret Pettichord's picture Bret Pettichord

Bret Pettichord is an independent consultant specializing in software testing and test automation. He co-authored Lessons Learned in Software Testing with Cem Kaner and James Bach and edits TestingHotlist.com. He is currently researching practices for agile testing. Contact him at www.pettichord.com or bret@pettichord.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!