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

behavior, focus on what can go wrong and focus on the severity of problems. Whereas good developers should be modeling system design, not user behavior. Focus on how it can work and focus your interest in the problem itself and the problem domain. So, that is coming in with two completely different perspectives, it is no wonder sometimes that there are clashes.

Bret: You're supposed to. There is a productive conflict that is supposed to happen with testing and development, and I think that is the goal for everyone, is to make sure that there is no conflict but that it remains productive and remains focused on the facts and remains focused on how to improve things, like you commented on finding saves rather just finding blame.

Carol: Right. And testers really need to be a user advocate, I guess, and a developers' advocate. I see them somewhat akin to a business analyst in that they are really kind of straddling two domains. They need to know enough about the development environment and enough in that area. They also need to know a lot about what happens in the user community. One of the things that you mentioned was that testers need to be able to model user behavior, such as mistyping, such as typing something in that might not be in the right sequence, or actually modeling what happens in the real world.

Bret: Well, that is a big area. Most software is designed to work well when it is used the way it is supposed to be used. As you know, whenever we try new things, we make mistakes. So, I always try to put a lot of attention on my testing; in fact, whenever I make a mistake in doing something, I say well is this a mistake that the user might make, because if so, then I am going to want the programming to be accommodating. I am not going to want it to destroy all of my data, I'm not going to want it to give me cryptic error messages. I am going to want it to somehow be polite to me, and help me back as we move along. And, I think that testers can do a lot of help with, is to try and look and usually those things are not specified very much in it. So, it is often when the testing comes in where we will really get to focus on what is the program behavior going to be for handling error messages.

Carol: Right. We will be back shortly with more of Bret Pettichord and talking about developers and testers after these short messages...I am back for our final segment of this show. We have Bret Pettichord, who is a lead developer, he has been a tester, he is a test manager, and a consultant. We have been talking about testers and developers. We have a caller on the line, Alex. You had a comment that you would like to share with us.

Caller: Yes. I would like to comment on the relationship between the developer and the tester. I believe that the developers and testers are in a kind of equal basis but the big difference is that they are looking at the same kind of product or module with a different perspective. The tester will try to see the whole thing with a kind of broader kind of width and the smaller kind of depth and exactly the opposite is the role for the developer. The developer will concentrate on making more depth in his own module, and