Test Managers-Start Managing!


Risk-based Testing
Risk-based testing is an approach to testing that assigns priorities to features and functions to be tested based on the risks associated with a failure in that feature or functionality. A test completeness goal will be assigned to each priority level. As illustrated in table 1, the higher the priority (Priority 1 is the highest priority), the larger the number of tests that must be executed. This helps to determine how best to limit test execution based on schedule constraints and also makes it easier to communicate this information to project managers earlier in the project lifecycle. Therefore, when the schedule begins to get slashed, which it undoubtedly will, there will be no question about what tests will and won't be executed and the potential risks involved.

With this information made available to project managers well in advance, a more thoughtful, deliberate decision can be made about how far to actually expand development at the expense of testing. However, this only works when you limit the number of tests/features/functions that can be assigned to each category. If everything is a Priority 1, you've defeated the purpose of prioritization. In addition, the number of tests and the average execution time per test must be calculated in order to effectively set testing goals.

Establish Trust with Subordinates
If you take care of your team, then they will take care of you, so stop passing the buck. Quit throwing your team under the bus. I can think of a million other clichés, but the primary message that I'm trying to get across is: Grow a backbone, and take care of your people! You are supposed to shield them from the politics on the project so that they may focus on actually getting work done. If your team members don't feel that they can trust you to stand up for their interests, then much of their time and effort will go into providing political cover for themselves, which will reduce the amount of time and effort they spend working.

In order to effectively stand up for your team, you must establish trust. You must be able to trust them, and they must be able to trust you. Having trust in your subordinates does not necessarily mean you have to assume they are getting tasks done, but it doesn't mean micromanaging either. Neither works well for the trust relationship. Instead, establish and enforce the use of standard templates and procedures, and set up a centralized location for regularly storing metrics that you, as a manager, can use to generate progress/trend graphs. Trend graphs are an excellent means of tracking progress without constantly standing over your subordinates' shoulders or requiring an overabundance of productivity-killing status reports. Test management tools are extremely effective for this job. If you have access to one, use it. Too often, test managers allow test management tools to be used just for storing tests and not for their full range of reporting and analysis capabilities.

Once you begin to trust in your subordinates, work on building their trust in you. One way to do this is to show them that they have your confidence. For example, if a testing disagreement between a resource on another team and one of your subordinates is brought to your attention, begin by giving your subordinate the benefit of the doubt publicly. Then, seek to clarify matters with them privately. Don't publicly assume that your team is incorrect. Also, limit the amount of overtime you will allow to be requested of your team. With the test completeness goals identified early in the project, you now have a basis for saying no to requests for overtime. And when you are able to get resources to volunteer for overtime (which is much easier to do when they feel you have their best interests at heart), make it clear to the project team that you and your team will only work the overtime when the appropriate support (development, networking, DBA, etc.) is also available. There is no bigger waste of time than coming in to do testing without support, because the minute something goes wrong with the system, testing is dead in the water. When you continually allow your subordinates' time to be wasted, they begin to get the feeling that you and the team don't value their time, and you begin to lose trust and productivity.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.