Some things in life, like death and taxes, are a given. Software development teams face their own givens: Project schedules will always change and certain teams will suffer because of these changes. If that's to be expected, then why haven't most managers done anything to save their teams from undue stress and abuse? In this column, Dion Johnson explains that we've got to take care of our teams, or else we'll never see the end of team abuse.
Some things are guaranteed in life. For example, we can almost certainly guarantee that none of us will live to be 200 years old. It's possible, but highly improbable. Another guarantee that can be made is that testing is going to be squeezed when it comes to the schedule. While it's possible that you'll be given sufficient time for testing and an appropriate ranking in the project's list of priorities, it is highly improbable.
Given this nearly indisputable fact, I must pose one question to some of you test managers out there: Why are you still being blindsided with these issues as if you don't know they're coming? Why are you allowing your team to be prodded into obscene amounts of overtime while other project members get to enjoy their weekends? Why are you allowing your team to be forced to provide last-minute justifications for unexecuted tests and unexercised functionality that are a direct result of schedule constraints? Why are you allowing your team to be the primary target in the finger-pointing game that will inevitably be played?
OK, that was more than one question, but I must say that I am absolutely baffled by the shear lack of preparation of some test managers. Mitigating these types of concerns is a fundamental job of test managers. So, if you're not doing this, then what are you doing? Despite popular opinion, simply attending meetings and transferring pressure does not constitute test management. I'm sure all of you know what I'm talking about, because we've all undoubtedly seen those managers that have become experts at looking busy and authoritative. They are always going to and coming from meetings, and when they receive pressure from the project managers, they simply transfer that pressure to the subordinate test engineers. When they get yelled at by their bosses, they transfer that aggression by yelling at their subordinate test engineers. This approach to management is not helping anyone, because nothing is really changing.
| Priority 1= 96% - 100% of cases tested Priority 2 = 81% - 95% of cases tested Priority 3 = 51% - 80% of cases tested Priority 4 = 21% - 50% of cases tested Priority 5 = 0% - 20% of cases tested |
| Table 1: Test Completenees Goal |
I'm under no illusion that there is some sort of magic solution that will make inefficient projects suddenly begin to operate more smoothly or that will completely shift the typical burdens off of the test team. What I am suggesting is that it is possible to manage expectations, slowly alter the predisposition to improperly squeeze the test team's schedule, and boost team morale. Some ways a test manager may accomplish these effects include:
- Employing risk-based testing
- Establish trust with subordinates
- Learning what money can't buy
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.Learning What Money Can't Buy
Often managers feel that they can make up for poor management and planning by throwing money at the problems on the project. For example, when projects face an approaching deadline that is in danger of slipping, there's often an inclination to attempt to assign more resources or try to automate quickly. However, the fact of the matter is that extra resources, test automation, and other attempts at getting quick results generally require more time in the short term. So, making such attempts at a moment when time is of the essence can be extremely counterproductive. Test managers must be able to effectively communicate this to project management to avoid making a bad situation worse.
As someone who has managed test teams and worked for both effective and ineffective test managers, I've seen the positive impact of successful mitigation of the known testing concerns discussed in this article, as well as the negative implications of failing to mitigate them. I therefore implore all test managers to do your job and find a way to effectively address these predictable circumstances, either by using the recommendations laid out above or by identifying your own.
