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 week's 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






