You're a test manager. Do you manage only the testing? Do you also manage support, documentation, and maybe computer labs? I meet a lot of test managers, and testing is only one of the things they manage.
At a recent workshop, Mike said, "With my SQA hat, I want to focus on finding defects and discovering risk in the product. With my support hat, I want to solve problems. With my tech pubs hat, I'm trying to get the documentation written. Last week, I felt really torn. My test group was having trouble quantifying risk and wanted some time with me. The doc group had discovered the installation scripts didn't work the way they were supposed to, and needed help from the developers and the testers. Our largest customer was having terrible problems, and I was trying to solve all these problems at one time. I'm only one person?how the heck do I do all that??"
I see several problems with test managers managing more than one function, at the first-line manager level. These other functions are not complementary to testing. Let's look at the objectives of these other functions:
Function | Primary Objective |
| Testing | Discover information about the product in development and report on those problems |
Support | Discover solutions to problems reported about the product already released |
Documentation | Discover information about the product in development and write descriptive information for potential users |
System Administration | Monitor the state of the network and the machines (fix problems where necessary) |
Release Engineering | Monitor development's progress and make builds |
Quality Engineering | Discover information about the product in development and report on those problems; monitor product development activities and work with development to find solutions to those problems |
So, why are all these first-line test managers managing work other than testing? My cynical response is that the senior managers don't understand the objectives of testing. The senior managers are looking at the number of people in the test group, not the actions of the test group, and basing their organizational decisions on that. Mike's VP in the above example said, "You only have four people in testing, only three people in support, and only two writers. Surely you can manage nine people. The development manger is managing ten people."
If your organization is based on the number of people in the test group instead of what the test group does, talk to your management. Explain the objectives of your group, and why it makes sense for you to be dedicated to testing. Explain the difference between testing and other non-software-development work. Explain what you could do if you were devoted to testing all the time. And don't forget to explain that it's harder to manage several functions rather than only one function.What could you do if you were the test manager devoted to "just" testing? Here are some ideas:
- Investigate areas of the product you haven't tested thoroughly yet.
- Gather those metrics you've been thinking of for the past few years, especially the cost of finding and fixing a defect.
- Review the defect reports for this release and the previous release or two, to see where the problems tend to cluster. Discuss those results with the test group and with the developers, to see if the testers or developers
should do something different. - Conduct a project retrospective and see where the project, and especially the test group, might improve.
Test managers can do a great job if they focus on and manage testing. As a first-line manager, it's a lot harder, and a lot easier to make mistakes, when you manage multiple functions.
