use of the tester's time. I am not sure it is a good indication of how good the tester is if they find things like that. Because a lot of times when people do this be-bugging stuff, this putting the defects in purposefully, they put them in places that especially black box testers cannot easily find. They make them strange boundary conditions. They make them very strange or abnormal use of the product or in exception handling. And testers do not typically find stuff like that easily. If you are not sure how good the testers are, it might be a better bet to actually out-source the testing in parallel with the current testing team and see how good your testers are. But, I would never recommend that people put defects in to see if their testers are any good.
Carol: It reminds me, and we were talking just quickly at the break about the Dilbert cartoon when Dilbert is going to be measured and rewarded for the number of defects that he finds, so he is busily injecting defects so that, what was it a minivan, that he--
Johanna: While he says I am going to build me a minivan this afternoon.
Carol: That's right. But I absolutely agree with you. I wonder sometimes whether products get shipped with some of these intentional bugs put in.
Johanna: Well, I wouldn't be surprised. I mean we ship with enough unintentional bugs. Why would we want to leave the defects in? If you cannot necessarily remember where they are, or if in the course of regular updating and fixing the code, you have somehow papered over it, you are not necessarily going to see where it is that you put it. It seems to me to be of a dubious--to me it is of really dubious quality. It does not seem to buy you anything. The risk potential is very high.
Carol: Right. We have a caller. Would you like to take a caller, Johanna?
Carol: Okay. Pam, you are online.
Johanna: Hi Pam, and welcome to the show.
Caller: I was interested in the topic when I saw it on the Web site of Test Management 101 because I am about to face that in my professional career, just being moved in as a test manager. I know testing, I have done testing, but I have really--this will be kind of an important move for me and I do not have as much experience in actually managing the people and managing the overall process. I wondered if you could give me some advice about that, and I will be happy to take my answer off the air.
Johanna: Well, there is a few things that I suggest. One is, of course, hire the most appropriate people for the job. You want to make sure that you are hiring people that give you a range of skills and that are appropriate for testing the software or the whole product that you have. But in terms of the sort of daily and weekly management, I think one of the most effective management tools is the one-on-one: the meeting every week between the manager and the employee. Where the manager says, "So, how is it going" and the employee says, "Well, here is what I'm doing and here are the issues that I am having trouble with, and here are the things that I want to investigate." It is a way to give and get feedback on a weekly basis. You don't have to wait for a performance evaluation. You don't