Creating Synergy and Pride in Software Testing Departments

In this chapter from Judy McKay's Managing the Test People: A Guide to Practical Technical Management, you'll learn valuable skills in motivating QA teams.

1 2 Page 2
Page 2 of 2

Good QA people want to deliver good products. The more ownership of a product or subsystem of a product they feel, the more they care about its quality. Part of their job satisfaction comes from knowing they did a good job managing the risks of the product and saving the customer from the horrors that the previously buggy software would have caused. Unfortunately, that's not really what the job is. As a manager, you need to make clear to your people what the job is not. It is not to ensure that the software has no bugs when it gets to the customer. It is not to ensure that the software is the coolest stuff on the market. It is not to ensure that every release will be shipped on time, and will be a stunning success in the field.

Our job is to provide factual information to the decision makers.

So what is the job? The job is to execute all the scheduled test cases to mitigate the priority risks. And, yes: You also want to find and document bugs, and accurately identify and classify those bugs. The job is to make a summary appraisal on the quality of the software by evaluating the risks. And, probably most importantly, the job is to provide factual information to the decision makers. This can be a very different picture from the expectations your people may have for their jobs, and the areas from which they expect to gain job satisfaction.

Risk Mitigation

Personally, I love to find bugs—the more complicated and elusive the better. That is what satisfies me. I am downright unhappy if I run a bunch of test cases and don't find any defects. If my test cases don't find bugs, does that mean I'm not doing a good job? Not at all. My job is to mitigate risks, not find bugs. The fact that I ran the test cases means I mitigated the risks those cases cover. You want to orient your group so that they are driven to mitigate risks, not find bugs. If the goal is to find bugs (or worse), and if evaluation is based on the number of bugs found, what happens if you get stuck testing software that's very solid and works well? We spend a lot of time testing things that work (we hope!).

You want to be sure you get the credit for all the time spent, not just the time that resulted in bug detection. Be sure to publish the test case execution results, and the risk mitigation results along with your bug reports. Upper management is often fixated on bugs found rather than risks mitigated, and these are very different results from the testing effort. Spend the time to train your management so they understand the goals. In this way you can reinforce those goals with your people, and increase their job satisfaction when they have completed test cases (whether or not bugs were found).

Ship It!

It's your job to constantly remind people that they don't have to agree with the decision to ship, but they are expected to provide accurate information. They don't have to fix the bugs, they just identify and classify them correctly. They don't need to take on a personal crusade for the quality of the software. If you can get these messages across to your group, they will be happier in their jobs, and will enjoy their contribution to their projects.

Those who like what they do will do a better job, work harder at it, learn what they need to know on their own time, and make their own rewards. You can't control someone else's job satisfaction, but you can provide an environment which will allow them to glean what they need.

Synergy, Pride and Celebration

Celebrate the little victories.

As you rise higher in management, it can be easy to forget to celebrate the little victories. You move from one project to the next; as soon as one project is past the crisis stage, you're on to planning the next one (the next project, not the next crisis!). It is all too common to forget to celebrate the completion of the previous project before turning to the next one. Don't forget. Just because your own reward system may have changed, you still have people who were fixated on a project for some amount of time. They need to celebrate the successful completion—have a party!

Creating synergy and pride within your department is your job. Be a leader! How much does it mean to you to get a pat on the back? Remember, as you go higher, there are fewer tangible rewards. (On the day I received a promotion, a friend rudely pointed out to me the higher up the tree the monkey goes, the more of what is seen is the monkey's behind.) Just because you don't get them doesn't mean you shouldn't give them. Be sure you recognize successes, and the effects of those successes. Your group may have just facilitated an early launch of a highly competitive product. They may not know that they were part of a project that just snuffed out the competition. Tell them! Celebrate the victories. Acknowledge and console when there are defeats as well. My department was once involved with a software release that never should have happened. It shipped (to our horror) on the scheduled date, despite the overwhelming evidence we presented. We knew the product would fail in the field, but we had done our job and supplied accurate information to the decision makers. Even though we felt rotten about the product, we had a project-completion luncheon anyway. We needed to spend a little time collectively as a group to discuss the business reasons why the decision to ship the product had been made, and I needed to remind everyone that we had done the job we were supposed to do. Everyone left the lunch feeling better about the work they'd done, and were energized to tackle the next project.

Never miss a chance to celebrate together as a group. Bring in doughnuts for hard days and nights. Give time off for extra hours spent. Treat people as if you are grateful for the work they've done, and the commitment they've shown. Remember, you are only as successful as your team makes you, so create genuine rewards for genuine effort. The little things do matter, so remember to say thank you, and send a nice e-mail now and then. Food is always appreciated, so take people to lunch or buy them bagels for breakfast. Make people glad they work for you.

Deflecting Criticism and Building Respect

You're part of the team that will provide the solution to the project's problems

You have to defend your department from internal and external forces. You may find yourself in the role of deflecting criticism. QA generally receives a lot of criticism, and that is partly because we generate a lot of criticism. Isn't that what identifying a bug is? We can say that it's documentation ofaberrant behavior, but to the developer, it is a criticism of their work. Frustration can run very high with developers, particularly when schedules are tight and bad bugs are found late in the process. Sometimes this will cause them to lash out, to you or to their management. So, what can be done toprevent hard feelings? As we've discussed in previous sections, a well-planned and well-documented test process will help relieve the frustration and finger pointing when the schedule blows up. Everyone will have already seen and agreed to the plan. You may not be able to follow that plan, but now you are completely within your rights to discuss any deviations with the stakeholders in the project. You're part of the team that will provide the solution to the problem; you're not the problem.

But What About Internal Problems?

In addition to deflecting criticism from outside your group, be sure your team does not explode from internal combustion. If you have problems brewing within (and you usually will), be sure you're constantly working to alleviate them. It is always best to learn about an internal problem from internal sources, but sometimes things boil over when you're not around. Be sure to listen! People need to feel free to talk to you or they won't bring you problems. If you're hearing about internal problems from external sources, you have communication issues in your department that need to be solved.

Be sure your group knows they can count on you. You need to be ready and able to act appropriately when faced with a personnel issue. If you criticize your group members to other people, they will find out and their trust in you will be destroyed. If you criticize group members to other group members, you should be shot. Well, maybe that's a little strong, but you get the point. There is no excuse for a manager to criticize one's peers. It makes everyone uncomfortable and destroys trust. The worst manager I've ever worked with criticized his people to non-management and management people, within and outside his department. Usually, a group with a bad manager will tend to band together against him. This is one of the least effective team-building strategies! In the case of this manager of mine, he created so much distrust between the team members that they hated him and they distrusted each other. It became the most dysfunctional group I've ever had the misfortune with which to work.

Don't confide in others inappropriately. If you need to talk about an employee, find another manager at your level. Or get a dog—they can always be trusted to keep your confidences. If you do decide to confide in another manager regarding your personnel problems, be sure you have an action plan. Don't just whine. If you're asking for advice, do so. But be prepared to act on that advice or explain why you won't. You don't want to appear weak and unable to deal with an employee problem. Be professional and think about what you want to gain from the discussion before you have it.

Remember to Remain Objective and Honest

When someone brings you an internal issue, what should you do? You want them to confide in you, but you don't want to give the appearance that you are agreeing with them. At this point, you need to be objective. You'll have to check the data to see if what you were told is valid, and determine if action is needed. Be very careful what you say, as it is likely to be repeated. If someone comes in your office and says, "I hate working with Joe; he's always such a grump in the morning," don't nod your head and say, "Yeah, I noticed." You can bet as soon as your complainer leaves the office, the whole group will know you said Joe's a grump in the morning, and you hate working with him. Depending on the speed of your grapevine, you can probably count on a visit from Joe before lunch, and he definitely will be grumpy!

When someone does bring a problem to you, be sure you are honest with them. Be sure they leave your office confident that they have given you information and you will act appropriately. This doesn't mean to encourage tattling. The last thing you want is to be resolving every little personnel issue that occurs. You are paying people adult wages and they should act like adults. At least that is what I keep telling myself. There is nothing wrong with sending someone from your office with the advice that maybe they need to work out the problem on their own, and they should come back if there are further issues.

Encourage and reward honesty.

You need to be sure that you have people in your department who will be honest with you, even with something you don't want to hear. I once made a presentation to my department in which I discussed a job classification change that affected the Senior Engineer requirements. Unfortunately, during the presentation, I misspoke and said Engineer instead of Senior Engineer. That would have made almost all the Engineers unqualified for their current jobs. I was very grateful for the person who raised their hand and asked for clarification. That would have been a terrible message to leave with the group. Encourage and reward honesty, and be sure you are honest in return. It generates and reinforces trust.

Include Your Staff Members in the Solution Process

Sometimes your department may be under fire, and you need to make some changes. What do you do? I once had a situation in which I had been told our customer felt the QA department was lazy. After significant investigation, it turned out they thought we were lazy because we allowed food in the lab, and they felt that people who were eating weren't working. On the contrary, by allowing food in the lab, people worked through breaks and lunchtime, and we were able to get maximum utilization of the equipment. The customer would not be convinced that this was an efficient way to work. They felt that chip bags and Coke cans in the lab indicated slovenly test habits. Rather than make a no-food ruling that would be seen as a significant negative to the work environment, I called a meeting with the entire department. We discussed the problem and reached the agreement that all food and drink would vanish from the lab when the customer was on the premises. At all other times, food was acceptable. Since they had been included in the problem resolution and had agreed to the solution, the group complied with the new rules and even enjoyed being part of the conspiracy.

If your problem is such that you can include your team into the solution process, do so. It allows them to see some of the issues you are dealing with, and makes them a part of the overall organization. In addition to getting your group comfortable with you, it's a good idea to make friends elsewhere in the organization. Create a solid, open working relationship with your peers, particularly the development peers. They can be your strongest allies or your worst enemies. You choose. You will almost always win your battle for more resources if you can present your case with backup from the development manager. You will almost always lose the battle if you don't have that backing. It is up to you to cultivate these valuable friendships and alliances. It may cost you a few lunches, but hey. You were going to eat anyway.

Excerpted from Managing the Test People: A Guide to Practical Technical Management, by Judy McKay. (Rocky Nook, $39.95 US, $51.95 CA. You can order it here.

Judy McKay has spent the past 20 years working in the high-tech industry with particular focus on software quality assurance. She has managed departments encompassing all aspects of the software lifecycle including requirements design and analysis, software development, database design, software quality assurance, software testing, technical support, professional services, configuration management, technical publications and software licensing. Her career has spanned across commercial software companies, aerospace, foreign-owned R&D, networking and various Internet companies.

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams