This week Michael Bolton wrote a nice story about a usual situation at work where the project manager asks a tester to come in for the weekend. As I just faced a similar situation with a colleague who was asked to stay in, I started to explain some of the mistakes I saw. Challenged by Phil Kirkham I also started to replace the testers behavior – placating – with another behavior – blaming. Today, I’m going to take a closer look on an improved conversation flow by using congruent communication. Just in case you’re interested in more about the Satir Interaction Model, I whole-heartedly suggest you to read through Weinberg’s Quality Software Management series, especially Volume 3 should be of interest.

Here is the list of prequels leading to this post:

• Management mistakes (Part 1) from Michael Bolton
• Testing and Management mistakes
• Testing and Management mistakes: Replacing placating with blaming

Since the conversation will not stay the same when led congurently, I am going to answer each of Magnus initial calls with a more congruent response as in the write-up, afterwards explaining how I constructed it.

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: “Hi Magnus. That is unfortunate. I know that you’re doing a great job managing the developers, but I already spent the last eight weeks at work. While my family still knows who I am, I really need time to recreate from work.”

Now, Magnus already knows that Tim will have a problem with turning in this weekend. However, he ignores this fact. The Satir Interactions Model is based on the three parts in each conversation: the self, the other, and the context. Magnus ignores the other in the whole conversation, so that is why Tim needs to raise the point to his self position. He is the one that couldn’t find time during the weekends with his family for the last two months. He has to raise the point that Magnus can understand what he’s asking from him – again. This may be achieved by explaining his self position. In the prequel of the response I added a short sentence so that Magnus knows that Tim does not ignore the other position – that is Magnus being a good project manager.

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: “I understand that urgency that you may be experiencing. The outlook on delivering that vast amount of bugfixes in the next release is great. However, the problem I see is that we don’t know if these bugs are really fixed, and how many other bugs they introduced by fixing them. It’s great to have three developers working on the bugfixes, but since I’m the only one who is testing those fixes accordingly, I’m the limiting factor here. Any time I spent with filing another bug that gets shipped to me, is time not spent on testing the outcome of the remaining fixes. Let me do some math here.

“Let’s assume they changed 27 portions of the code. Now, if each bug takes two minutes medium for me to test, I would be quite finished when testing through the 27 areas of the bugfixes in say a 90 minute test session. Great. But we have some data from the past. Our developers introduce two new bugs for each fifth fix they apply. This means they would have roughly introduced eleven new bugs while fixing the others. These eleven bugs I would have to file during my test session. As bug reporting and follow-up testing takes a bit more time than just testing the application when everything is fine, I will need more time spent on these. A medium bug report takes ten minutes. So, during a 90 minute test session I could roughly test 15 bugfixes taking 2 minutes to test each, find the six new bugs and file them, which takes 10 minutes each. So, I would at least need another 90 minute test session to follow-up on the initial 27 bugfixes overall. But then after that I would need to go through the eleven newly introduced bugs in a third session, leading to five new bugs, and so on.

“Now compare this with the situation we get, when our developers would test and review the bugfixes thoroughly before I get the new build. We could reduce the introduction of new bugs from two for each five fixes to maybe one for each ten fixes. This surely would free up my time for testing. Sure, there would be less bugfixes that seem to be fixed, but we’ll never know if the bugs really got fixed. We just know this after they got tested.”

Here, I tried to apply a rapport approach. The project manager seems to be fascinated by numbers, so Tim used the same approach using numbers to explain the situation to the project manager. In practice you don’t need real numbers, you might guess them, but the more precise numbers you can get, the more relevant your response will become.

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: “No, sorry, I am not quality assurance, rather quality assistance. Putting a stamp such as “approved” on the software, surely would mislead you. Given the time I get to work on testing the product, I can tell you whether or not I perceive it to be of quality or not. This does not necessarily mean that it is of quality to our customers per se. I assure you that for the time I get to test the product, I can give you information about it’s usefulness. I assure you that I try as hard as possible to understand the needs of our customers and incorporate my understanding from it into my testing. But, assuring that the software works needs the external and the internal perspective. I can just tell you about the external perception of the production. The internal perception includes the adaptability of the software to tomorrow’s needs, to changes in the requirements and to unforeseen use of the software.

“From the information you already have about the build process failing and the developers busy to fix the build and the bugfixes under time pressure, I can tell you that the software does not seem to be in a good internal shape. These are of course quality related, but since I don’t have any influence on them, I would mislead you if I would assure the quality of the software. Here, take this book, [handles a copy of Perfect Software… and other illusions about testing], read it, read it twice, even three times if necessary. I could also read it for you, if you’d like. THAT is a service I would offer; assuring quality software isn’t.”

This one is the hardest part. There is a big misconception about testing and what the expected outcome from successful testing is. Testing does exercise the product, but mostly we focus on the external viewpoint of the product. If you run into this situation yourself at work, you will surely have a difficult time to clarify the misconception and help people change their viewpoint of testing. My article “Testers in the Gatekeeper Role” in the Software Testing Club Magazine No. 1 has some pointers on how to tackle this one.

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: “No, I’m sorry. You seem to know better about software than I do. Therefore I would propose that you come in and test the software on Saturday. On one hand you say that I’m the expert, but on the other you prescribe me what to do. If you really think I’m the expert on testing and/or software quality, I would expect that you trust that expert opinion.”

There is a fine line here between Tim’s response and a blaming response. The third sentence is really on the edge to go into a blaming response here. But by making the point clear, that Magnus says on the one hand, he’s the expert, and in the next response not to trust the expert’s opinion about the software, Tim brings back congruence into this conversation.

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: “Ok, we got two weeks to go until. The current state of testing indicates already that we’re behind schedule. The problems we already found indicate that there seems to be a more severe problem in producing the software. I am pretty sure you do a great job of managing the project, but the reflection from the last project showed that merely two percent of the escaped defects could have been covered by the regression test suite that existed at that time. Therefore, I would propose to look on the cases that are not covered by our regression tests more intensively.”

Putting in additional information from the cited project may bring back sanity to this project manager. Having results from a reflection workshop or retrospective can be used very wisely here. The manager does not seem to be aware of the root cause for the escaped defects. So, by reframing the discussion here about the problem that underlies the assumption of fixed requirements and fixed test cases might bring back the project back on course. Of course, making such suggestions is a way to lead the project, so be aware to formulate it as optional for the project manager to take the necessary action. Thereby it’s more likely that he will understand the underlying system and the dynamics of it.

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: “Well, you are right, we don’t have time. But the reason why we don’t have any time is that we’re busy with retesting all the bugfixes that introduce new bugs. What I think we would need is to free time spent during testing, so that we again have the flexibility to continue working on new features. The only way to achieve this is by delivering more bug free software to us testers.”

Magnus is asking here for more time indirectly. So, a proper response from Tim must include a reaction to that claim. He has to show a way how to free some more time – in the short-run and in the long-run. Of course, Magnus has to understand that in the short-run he has to sacrifice some of his beloved progress, but the pain is paid back in the long-term when this vicious cycle is stopped.

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: “Sorry, Magnus. I know you tried hard to get our programmers up and running. But if we do not find new problems here, our customers surely will find them and report them back. Our reputation will suffer, as well as our market share. When the software ends up no longer being bought, we may deliver anything from here. If the product does not need to work, we can basically deliver anything. That’s why I think exploratory testing is not a luxury, but a necessity.”

Again, in this response I tried to incorporate the congruent strategy. Tim appreciates what Magnus has done, brings in the context of the matter and finally makes his own perspective clear. As introduced by Norm Kerth in Project Retrospectives, Tim could additionally ask Magnus for his involvement into the actions necessary from the reasoning he began. Thereby he would of course raise Magnus’ buy-in to carrying out the agreed solution.

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: “I’m sorry, Magnus, but this is my quit notice. I really tried to bring the best I can to this project, but for the sake of my family and myself, I must leave this company. Goodbye.”

Of course, this might seem to be a strange reaction, but after having piled up all these reasons, it’s obvious that this poor manager is not managing anything. He’s not managing the sales and the CFO, he’s not managing the support group, he’s not seeing the disaster he has created by doing so. I don’t have any hope on this. Sure, quitting may seem to be an extreme reaction, but I don’t see a good way to tell this manager to reject all his illusions about the project.

So, to conclude, you may ask, did I use one or another of these responses? I must admit, I tried whenever I was aware about it. Oh, and don’t think I did a good job. There are lots of problems in the responses I wrote. How many can you spot? Dealing with the situation at hand needs to take into account the context of the situation. Your Magnus and your Tim in your organization may react differently to some of the phrases in my responses. The technique is relevant.

On a final note, I would like to point out to Weinberg’s Process Improvement Lessons from Quality Software Management Volume 4.

Individual issues often underlie the toughest improvement situations. Cultural changes will involve upper managers. You can change the logical process first, bug consider this a test to see if the problem is entirely logical. To address emotional problems, you’ll need to get under the surface to the layers of information protected by the cultural rules governing what’s not okay to talk about. Be careful that
changes are not made in a blaming way. A policy of not blaming does not mean a policy of placating.

That said, try these responses in order to get to know whether the underlying problem is logically. If it isn’t you will have to deal with the emotional problem underlying the problem you perceive. Bolton’s initial conversation included placating behavior from Tim the Tester, my last conversation included blaming behavior. Both did not work, and I surely picked some responses here which are on the edge to become blaming. In the end, breaking the cultural rules will surely need patience on both sides, but in the conversation at hand you have to help the project manager cope with the problem that he does not know how to manage properly.