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?
my observation:
Typical conversation often i have heard of. from this conversation above,
1. Magnus doesn’t seem to understand the QA process and where it fits in the project cycle – this includes an understanding gateway but not doing right things on soft skills with respect to transparency, and what, where, how the fixes are made.
2. Agreed, Tim, from this story, isn’t assertive enough to convey what he wants to.
3. Planning: If Tim thinks there were more scenarios missing, perhaps, he/his team could have planned better upfront, if not for specific test cases, but at least could have planned in the schedule to allocate the time as appropriate.
4. from project management perspectve, Magnus should discuss [a]the fix and build schedule [b] discuss the fix process for defects [c]allocate the time required for sync ups between teams or perhaps adapt a project management methodology that helps to keep the functional teams in sync
5. Cycle time: Magnus doesn’t seem to still think the cost of defects found in completed builds and not moving the test upfront where the cycle time could be minimized. Time = Money. If he was willing to take that kind of hit, then he should have planned for such cyles in his schedule.
6. “..they don’t have time for testing..” well, that sounds like PM is signing up for schedule and project issues. Why not plan for Unit Testing? and certainly take help from test team as appropriate, but unit test and integration test before dropping the builds to the test environment is a must.
7. Project manager here may not get the same support for future projects from same resources with the attitude of request and planning process depicted here, unless he learns from this experience.
Michael’s reply: I appreciate your comment. I’d like to suggest a reframe, though: consider de-emphasizing planning where you can emphasize preparation on the one hand and doing on the other. You can be prepared to deal with problems in a product or in a project, but it seems funny to me to plan for them as such. I may have to go over this distinction in a later post. There’s little need to plan for unit testing if you mandate doing it.
Great story. Personally, I tempted to answer your challenge in a longer response. Therefore I set up a follow-up blog entry: http://blog.shino.de/2010/03/29/testing-and-management-mistakes/
Actually, it sounds very familiar from BOTH of my “development life” phases – as a developer/tech lead for development and in Testing/QA.
A few years ago, I could easily have found myself in “Tim’s” position – wanting to do good work, and hampered by everything from “sudden changes in urgency” to lousy builds. Until Tim figures out, as I did, that sometimes the BEST answer for the team and the company is “No,” he’s going to be on the short end each and every project.
Until Magnus takes a serious stand in *managing the project* (as opposed to managing MS Project Gannt charts) things will continue to be unstable.
When I was wearing my PM hat, I found that one of the most effective ways to improve the builds/code stability was to require development and build management staff to be in the office the same hours that people were expecting test staff to be in extra – weekends, nights, holidays, whatever. If something is important enough for test professionals to sacrifice their weekends and family time for the project, then the entire team should be expected to make the same sacrifice.
And the bosses buy lunch/supper on those days.
I’ve been involved in the situation you describe and unfortunately it took years to solve. In the end, it was resolved through a process where by the testing team introduced what we called at that time “end to end” tests which were acceptance tests for a build that came from the development team. This phase in the software development cycle was introduced to prevent “crappy” builds getting to the testing team. The testing team wouldn’t accept the build until all of the tests passed. Once the tests passed, the product was deemed testable and the testing cycle began. Evening and Weekends were worked and time in lieu was offered but at the end, the release day was always delayed.
After a few cycles of the end to end phase that were painful, the development quickly realized that unit testing would speed up the process. Perhaps Tim could introduce an “end-to-end” phase to protect himself from working weekends and to keep the build on the development side of things (assuming the company is using a waterfall SDLC).
The biggest one: “The programmers upstairs…”
The organization needs the programmers and testers working together. What they’re doing now reminds me of dredging oysters. The programmers dump a bunch of crap on the deck and the testers drop to their knees and fish through it for the oysters amongst the mud and shell.
[…] is a response to a recent blog entry from Michael Bolton. He challenges to spot as many management mistakes as possible in a short […]
I have been many such situations – build coming up by Friday end of the day (developers need to rest, defocussing so that they can come back fresh next monday to fix the issues reported in week end testing)and testing team slogging week end.. (some ocasions, development team was on the call… we called them several times to verify bugs and even some small fixes).
Another mistake management makes in such cases is to plan for release once a cycle of testing is completed after the build. They fail to realise (or have fixed backup plan) that every cycle of testing produces its own set of bugs (hence fixing and hence more testing… that is an inherrent nature of software, we cann’t help it).
Instead of leaving developers “undisturbed” and isolated -Magnus should help them with testers to do pair testing with developers – while “leaving developers alone” might look like an apparent good thing to do so that fixes can be done quickly.
Shrini
I have been into this Situation myself and like Tim i was also undergoing several mind shifts between Yes and No.
Was not knowing how to directly say NO and was used to do what the managers wanted me to do, they never understood problems which i uncovered from exploratory testing as they were not imp to them and it was out of scope for our team, instead their main focus was that Test cases should pass and thats all what matters to Stakeholders according to them at that point.
I feel that Magnus should take well informed decisions by all the information he already has and not just stress on getting test case execution as the acceptance criteria. He should learn to see the product from Quality Point of view
and take good Unit Testing to be done by the development team as the First Step for the test team to accept or reject a Build.
Madhukar
[…] 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. […]
[…] 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. […]
“What do you think?” – I think Tim needs to quit his job. There’s no helping an organisation with a culture like this and Tim can’t change anything from where he is.
“[D]oes this conversation feel familiar to you?” – Yes. I’ve had similar conversations at a previous employer. I put up with it until I recognised that I couldn’t change those fundamental problems and then I got out.
[…] Management mistakes (Part 1) from Michael Bolton […]
It is very easy for us to comment at things in retrospection… But, we will have to look at ground reality and do what’s best in the interest of the organisation.
In this case, things have already gone for a toss and best way forward would be for Tim to come in on Saturday and complete the current release.
We see things differently. I’d be inclined to suggest that the best time for Tim to start learning to say No is right now. Unless he wants to come in next Saturday. And the Saturday after that…
Tim should realise that his life is messed up…It’s up to himself as to how he gets out of it. He should realize that he should have had the foresight to foresee these problems in the project, when he signed up for the project. Am sure that Tim would have already known about the dev team, management team, etc… If it’s a first project for Tim, he needs to think of what he can do to ensure that it does not happen again.
What Magnus needs to do is — promise to arrange a retrospection meeting to ensure that this does not happen again. 1st time mistakes are understandable (Won’t we all be out of a job if nobody makes mistakes? :))…. But, Magnus needs to block time for a project post-mortem to understand the root causes for the problems that resulted in the current steps and put in sufficient processes to ensure that they don’t repeat again. Looking @ the conversation, 1 would be on investment on automation, 1 on automated testing before releasing to test, maybe an agile project process, a suitable project process such as CMMi or 6-Sigma to control defect leakage, etc. etc. etc…..
—Fake Software Tester (too shy to sign)
I think a retrospective would be a good idea if (and only if) Magnus is going to learn something from it and do something about the problems that it highlights. As for the process-oriented approaches to solving the problem… well, media (in the McLuhan sense, so process models are media too) extend, enhance, accelerate, and intensify human capabilities and tendencies. Models can accelerate or intensify awareness, effectiveness, or efficiency. Yet Magnus is clearly a pretty unaware guy, so I’d be careful: the process models might serve to accelerate or intensify his unawareness, his ineffectiveness, or his inefficiency.
—Michael B.
What do I think?
I think your statement about writing fiction holds true. It’s hard to connect with one-dimensional characters.
Is this writing dialog or fiction? or is it both? I’m confused.
Does this conversation feel familiar?
I supposed it might be – which part of the conversation where you referring to?
You’ve told me a story – which is interesting but what’s the general theme you were getting at?
Is it that Tim needs to stand up for himself? Is it that Magnus is a bad manager? or is it that Magnus doesn’t understand software? Tim is expected to have more influence and doesn’t? Or maybe Magnus understands his context and what is best for the business. (perhaps it’s a startup and this is their first release). Maybe they are going out of business and the best thing to do is get it out the door. Mangus might be a genius that is going to save/make the company millions!
Or is this one of your trick stories where I’m supposed to pick up whatever I pick up because that’s what I was meant to learn in this instance? Now there is a McLuhan reversal for you 😉
[…] it or keep waiting As Michael Bolton mentions in his blog post Management Mistakes Part 1, I usually don’t like fiction writing in the form of dialogs. I’m not good at the form, which […]
[…] it or keep waiting As Michael Bolton mentions in his blog post Management Mistakes Part 1, I usually don’t like fiction writing in the form of dialogs. I’m not good at the form, which […]
Other possible answers:
Tim: “Sure, I can come in. Can I get Monday off if I work Saturday?”
Tim: “Sure, I can come in. Will the DEV team be onsite to assist me when I pick up a bug? Otherwise I might only test 10 minutes and get stuck on a showstopper.”
Tim: “Sorry, apologies, I have an important arrangement on Saturday, but John (other tester) is available on Saturday, he can come.”
Tim: “No problem, can I claim overtime?”
Tim: “I told you this is going to happen earlier this week. Why haven’t the developers worked 10 hours on Tuesday, Wednesday and Thursday, then we would have the full Friday for testing?”.
Tim: “We are WAY behind anyway. Even if I come in Saturday we are already 3 weeks behind schedule, will it make any difference?”
[…] }); } As Michael Bolton mentions in his blog post Management Mistakes Part 1, I usually […]