Wednesday, May 6, 2009
Provide Test Expertise to Test Group
Ability to discuss, mentor, and/or train current employees on general testing techniques.
Ability to look forward to the products in development and planned for development, to foresee what new expertise and training is needed by the group.
Ability to hire people based on current and future testing needs.
Note that this does not mean the test manager has to provide specific low-level tests for the product. A test lead's job is developing tests, not the test manager. As a test manager, you provide leverage to all the testers and to corporate management. You need to define for yourself the difference between mentoring and doing other people's work.
Develop Test Strategies
Define and Verify Product Ship Criteria
It's important for testers to prioritize their testing so that the product ship criteria can be met. Since very few projects have enough time to do everything, getting the testers enough information for what and when to test is a very important role for the test manager.
Corporate managers need to understand the product ship criteria enough to be able to judge whether the product is ready to ship at a given date. I don't believe the test group should be either the holder of product approval or rejection-that role belongs to corporate management. Having pre-negotiated, agreed-upon ship criteria helps corporate managers judge for themselves whether or not a product is ready to ship. Pre-negotiated criteria helps the project team decide what product quality is when one no one is stressed from the project work.
Gather Product Information
The successful test manager also gathers product information, in the form of defect counts, test pass rates, and other meaningful data. The test manager defines the data, and then gathers it for presentation to corporate management. For example, I gather what I consider to be the "basic" metrics:
Defect find and close rates by week, normalized against level of effort (are we finding defects, and can developers keep up with the number found and the ones necessary to fix?)
Number of tests planned, run, passed by week (do we know what we have to test, and are we able to do so?)
Defects found per activity vs. total defects found (which activities find the most defects?)
Schedule estimates vs. actuals (will we make the dates, and how well do we estimate?)
People on the project, planned vs. actual by week or month (do we have the people we need when we need them?)
Major and minor requirements changes (do we know what we have to do, and does it change?)
Measure what you’ve done
When your efforts have more to do with team performance and avoiding disasters than a tangible product, how can you measure what you’ve done in a concrete way? If you are a test manager, here are some ways to measure what you’ve done:
How many people have you unwedged or unblocked this week?
Sometimes our staff may not realize they are stuck trying to solve problems. If you are able to recognize that someone is stuck and point them in a more useful direction, then you’ve accomplished valuable work.
How many of your staff were able to get more work done this week, based on what you said?
Managers leverage the work other people do. When you facilitate other people’s work, then you’re doing management work. If you discussed test plans or your staff’s choices about which tests to implement, then you’ve helped people leverage their work.
How much strategic work did you do this week?
Managers set the strategy for their groups, and then put the tactics in place to make it happen. Maybe you’re working on improving your test capability with a new test lab, or arranging ongoing education for your testers. Maybe you’re working on decreasing time to market by changing how you plan your projects, or how the developers and testers work together. Strategic goals are long-term goals, so you’d expect to make only a little progress on strategic work each week. But the effort you invest and the progress you make certainly count.
How many crises did you prevent?
Every time you solve a problem and prevent a disaster or crisis, you’ve allowed your technical staff to go forward. For example, if you realized early enough in the project that the developers and testers were working toward different goals, and you started developing release criteria, you’ve averted plenty of problems and a potential ship crisis.
How many meetings were you able to cancel?
Unfortunately, too many of us work in meeting-happy organizations. A meeting that doesn’t include the following characteristics is not likely to help your project or your team move forward:
It starts on time
It ends on time or early
You can leave the meeting if you’re not needed
Action items come out of the meeting
The meeting has an agenda and minutes
If you are able to cancel meetings that don’t actually help move a project forward, then you’ve done wonderful management work. Look for these opportunities and take advantage of them when you see them.
These are just five ways to measure your managerial output. You may want to create a short checklist that you review each week to keep track of your efforts. Any work you do that helps your staff and the long-term health of your organization is good, tangible work. Count it.