Creating Synergy and Pride in Software Testing Departments

CIO — Excerpted from Managing the Test People: A Guide to Practical Technical Management, by Judy McKay. (Rocky Nook, $39.95 US, $51.95 CA)

We Love Us, Why Doesn't Everyone Else?

Managing the Test People: A Guide to Practical Technical Management

It's time to be honest here. QA is often considered a necessary evil. This isn't exactly the description we were hoping for when we took the job. I bet you didn't go to college and look at the career center postings thinking, "Ah, Necessary Evil, that's what I want to be." On the other hand, the "necessary" part is a good thing. QA has to be recognized as necessary. Once you've hurdled that obstacle, you can fix the evil (unless of course you like being referred to as evil, in which case you might want to consider a different career—we don't need you cluttering up the world of QA).

Emphasize the Necessary
How do you make sure your department is considered to be necessary? By providing a tangible product. Remember, you may be competing for funding and headcount with development. If the VP of Engineering has money to spend, how will he decide? If he spends it on development, he'll get this cool new program that does stuff. If he spends it on QA he'll get...what exactly? More bugs identified? Well, what good is that? You need to be sure your department is producing a tangible product that can be understood and described to your management. Did you already do the test plans?

Great. You probably also keep track of the test cases, and the bugs you find. But what does that mean to your management when they are thinking about spending money on you? Can you guarantee to your boss that if he gives you two more people, you will find 500 more bugs and make the product safe for humanity? No. But the development manager can promise that two more people will result in two more cool programs that can be seen, demonstrated, and sold for revenue.

Determining ROI (Return on Investment) for QA
This has always been a quandary for us in QA, and particularly for QA management. For all the years I've done QA management work, this has been one of the most difficult aspects of the job. Fortunately there is a good way to track and project what the QA group will accomplish, and how additional resources will affect the outcome of the goals. I'm a strong advocate of approaching quality assurance as a risk management function. Given any project (of any size), you first define the risks that you are trying to mitigate. What are all the bad things that could happen if this software doesn't work? It is a scary thought, isn't it? But that's where you start.

Continue Reading