Testing and Management mistakes: Replacing placating with blaming

Phil Kirkham suggested in the comments on my entry about Testing and Management mistakes to do a write-up on how Tim could have responded in a better fashion. Personally, I decided to show to fashion of this: the incongruent style and the congruent style. Today I will begin with the incongruent one, providing a more congruent view in a later blog entry. Just in case you haven’t read the source of inspiration from Michael Bolton, yet, you can read it here.


In this write-up I will quote the initial response from the project manager and how an incongruent response accordingly from Tim the tester could look like. While I assume that the responses from Magnus the Project Management would be very different, I will leave them in as is, though the story might be deteriorated be then.

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: “No way. You already had me spent the last eight weekends in a row here. I’m not going to give in to your stupid claim this time.”

Magnus: “[…] 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: “Yeah, sure. A new build full of new bugs, which they cannot test for themselves. Did the programmers sent you how many bugs they incorporate while fixing all of those? How come they are incompetent at testing their very own crappy code?”

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: “Of course, you don’t know. The point that the build is unstable doesn’t tell you anything regarding the quality of the fixes of the code from our poor developers either, heh? And I’m not assuring that the code they produce has any form of internal quality in it. I don’t even have a clue about that mess they keep on producing, either!”

Magnus: “Of course you do. You’re the expert on this stuff, aren’t you?”

Tim: “I’m an expert on software testing, but not an expert on software management and not an expert on software development. If I were, I would know that testers, developers and stakeholders needs to collaborate throughout the project, despite sitting on two different floors without even talking to each other over a different tool than the bug tracking system!”

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: “Of course we have a more urgent problem all the time. And why bother programmers with failing tests anyways? We could as easily throw away our bug tracking system and ship without even reviewing the code! On a side note: I cannot and will not be here on Saturday. Period.”

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: “On that last project we had a high defect escape ratio just because you were ignoring the very facts that should matter. How crappy will be the next code drop and that thereafter? Besides those regression tests we wrote down one year ago are outdated. They’re completely outdated, useless pieces of text, not even worthy the paper they’re written on. We would be better off throwing them away completely, and starting to do them over! NOW!”

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: “So, we’re using useless test cases. Great. What’s the outcome you expect from those? In that case no test cases were better than wrong test cases given false safety!”

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: “But we can afford the even luxury to do them over and over again? Sure… Magnus, you haven’t listened to me well before, but I am definitely not going to be here this weekend. There is no way you may force me to.”

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: “And as I said, you keep on ignoring these facts that may point you out to the problems in the software at hand. I’m not going to give in. You will need to escalate this up to the CEO level, but I’ll still refuse to be in here on Saturday. I’m tired of your lousy management actions that lead to nothing in the end. Go where the sun doesn’t shine with your weekend overtimes!”

Magnus: “Ok, we’ll meet back at the CEO, then.”

Reflection

Now, don’t do this at work, kids! I hope you read up until here. I vastly exaggerated here. What I basically did, was to replace the previously placating behavior from Tim with blaming behavior. Since Magnus is also blaming there is an immense conflict now between the two. This conflict is surely just going to be resolved by either one of them quitting the company completely. Well, on the other hand, maybe that is exactly what you want to do, but it’s usually just a survival response to keep yourself sane after such a long overtime period. There are better ways to respond to that project manager’s claims without ending up in a conflict situation. I’ll point out to these in later blog entries.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

One thought on “Testing and Management mistakes: Replacing placating with blaming”

Leave a Reply

Your email address will not be published. Required fields are marked *