Phil came into my office, and flopped down into the comfortable chair across from my desk. He looked depressed and worried. “Hey, Phil,” I asked him tentatively. “You look like something’s bothering you. What’s up?”
His brow furrowed. “I don’t know. I just don’t know. Sometimes I feel like people think of me as nothing more than a literary device.”
I usually don’t like fiction writing in the form of dialogs. I’m not good at the form, which leads to me not practising it, which of course leads to me not being good at it. The problem that I see in many dialogs is that the characters are at best one-dimensional. They’re trapped in an artificial story. I don’t connect with them if I don’t care about them, and I don’t care about them if I don’t connect with them.
And yet I do hear about real-life dialogs from people that I connect with and care about very deeply. Those people are testers that I meet all over the world. Everywhere I go, they tell me about conversations they have with their managers. What follows is a compendium of things that I hear at least once at every conference. It’s an exaggeration, but based on what I’ve heard consistently from testers worldwide, it’s not a major one. In my defense, it’s a dialog, but it’s not exactly fiction.
Magnus the Project Manager: “Hey, Tim. Listen… I’m sorry to give you only two days notice, but we’ll be needing you to come in on Saturday again this week.”
Tim the Tester: “Really? Again?”
Magnus: “Yes. The programmers upstairs sent me an email just now. They said that at the end of the day tomorrow, they’re going to give us another build to replace the one they gave us on Tuesday. They say they’ve fixed another six showstoppers, eight priority one bugs, and five severity twos since then, and they say that there’ll be another seven fixes by tomorrow. That’s pretty encouraging—27 fixes in three days. That’s nine per day, you know. They haven’t had that kind of fix rate for weeks now. All three of them must have been working pretty hard.”
Tim: “They must have. Have they done any testing on those fixes themselves?”
Magnus: “Of course not. Well, at least, I don’t know. The build process is really unstable. It’s crashing all the time. Between that and all the bugs they’ve had to fix, I don’t imagine they have time for testing. Besides, that’s what we pay you for. You’re quality assurance, aren’t you? It’s your responsibility to make sure that they deliver a quality product.”
Tim: “Well, I can test the product, but I don’t know how to assure the quality of their code.”
Magnus: “Of course you do. You’re the expert on this stuff, aren’t you?”
Tim: “Maybe we could arrange to have some of the testing group go upstairs to work more closely with the programmers. You know, set up test environments, generate data, set up some automated scripts—smoke tests to check that the installation…”
Magnus: “We can’t do that. You have high-level testing to do, and they have to get their fixes done. I don’t want you to bother them; it’s better to leave them alone. You can test the new build down here on Saturday.”
Tim: (pauses) “I’m not sure I’m available on Sa…”
Magnus: “Why not? Listen, with only two weeks to go, the entire project depends on you getting the testing finished. You know as well as I do that every code drop we’ve got from them so far has had lots of problems. I mean, you’re the one who found them, aren’t you? So we’re going to need a full regression suite done on every build from now until the 13th. That’s only two weeks. There’s no time to waste. And we don’t want a high defect escape ratio like we had on the last project, so I want you to make sure that you run all the test cases and make sure that each one is passing before we ship.”
Tim: “Actually, that’s something I’ve been meaning to bring up. I’ve been a little concerned that the test cases aren’t covering some important things that might represent risk to the project.”
Magnus: “That might be true, but like I said, we don’t have time. We’re already way over the time we estimated for the test phase. If we stop now to write a bunch of new test scripts, we’ll be even more behind schedule. We’re just going to have to go with the ones we’ve got.”
Tim: “I was thinking that maybe we should set aside a few sessions where we didn’t follow the scripts to the letter, so we can look for unexpected problems.”
Magnus: “Are you kidding? Without scripts, how are we going to maintain requirements traceability? Plus, we decided at the beginning of the project that the test cases we’ve got would be our acceptance test suite, and if we add new ones now, the programmers will just get upset. I’ve told them to do that Agile stuff, and that means they should be self-organizing. It would be unfair to them if we sprang new test cases on them, and if we find new problems, they won’t have time to fix them. (pause) You’re on about that exploratory stuff again, aren’t you? Well, that’s a luxury that we can’t afford right now.”
Tim: (pauses) “I’m not sure I’m available on Sa…”
Magnus: “You keep saying that. You’ve said that every week for the last eight weeks, and yet you’ve still managed to come in. It’s not like this should be a surprise. The CFO said we had to ship by the end of the quarter, Sales wanted all these features for the fall, Andy wanted that API put in for that thing he’s working on, and Support wanted everything fixed from the last version—now that one was a disaster; bad luck, mostly. Anyway. You’ve known right from the beginning that the schedule was really tight; that’s what we’ve been saying since day one. Everybody agreed that failure wasn’t an option, so we’d need maximum commitment from everyone all the way. Listen, Tim, you’re basically a good guy, but quite frankly, I’m a little dismayed by your negative attitude. That’s exactly the sort of stuff that brings everybody down. This is supposed to be a can-do organization.”
Tim: “Okay. I’ll come in.”
How many management mistakes can you spot in this conversation? In your opinion, what’s the biggest one? Here are my nominees:
Tim needs to manage his responses. He needs to learn to say No, quickly and directly.
Magnus needs to recognize that testing’s job is to gather information that will help him make decisions about the product, and that he already has more than enough information to start making decisions. He’s making a lot of mistakes here, but his biggest one is that he has closed his eyes and ears to the information all around him, and he’s not managing the project. More testing won’t help him, and Tim is already done, for now. Magnus needs to start managing the project. He needs to give the programmers time to fix their problems and test those fixes. Since the overhead for investigating and reporting bugs is so high and so damaging to test coverage, he needs to require better builds from the programmers—and he needs to provide them with the time and the resources to do that. He needs to co-ordinate the services that his testers can offer with the services that the programmers need.
Two questions for you: What do you think? And does this conversation feel familiar to you?