Read an Excerpt
Chapter 9: The Triumph of Politics: Organizational Challenges for Test Managers
...TEST IS NOT AN ISLAND: EXTERNAL EFFECTS ON YOUR PRODUCTIVITY
Various organizational behaviors and attributes, which I call "gas pedals" and "brake pedals," can speed up or slow down test progress. In general, all of them exercise incremental influence on your test operation: a single tap on the brake won't bring the test project to a dead stop, just as a jab to the gas won't send the system under test rocketing through the test exit criteria in a single pass. Overall, however, to make testing proceed smoothly, your company needs to press on the gas pedals and lay off the brake pedals. Although each single incident or behavior is incremental, it can be part of a troubling trend.
Your test project can easily suffer the "death of 10,000 cuts" from many little braking events. In a reactive sense, when the project takes a significant hit, you should document it in the change management database introduced in Chapter 6. However, the broader theme of this chapter - the challenge of politics - suggests that you use your relationships and your influence with management and peers to be proactive. Try to recognize any trends of inhibitors that develop, in order to prevent or reduce their occurrence in the future. Likewise, you can actively promote behaviors that make your job easier. Help your peers and colleagues understand that following certain courses of action and eschewing others have important effects on your productivity.
The following organizational behaviors and attributes tend to accelerate the test process. Encourage these activities and values among your peers, and set a good example in your own work as much as possible.
Testing Throughout the Project. I use the phrase "testing throughout the project" in a three-dimensional sense. The first dimension involves time: in order to be properly prepared, and to help contain bugs as early as possible, the test team must become involved when the project starts, not simply at the end. The second dimension is organizational: the more a company promotes open communication between the test organization and the other teams throughout the company, the better the test group can align its efforts with the company's needs. The third dimension is cultural: in a mature company, testing as an entity, a way of mitigating risk, and a business management philosophy permeates the development projects.
Employing Plenty of Good Technicians. As Chapter 8 explained, you can get qualified test technicians from the computer science and engineering schools of local universities and colleges as well as from technical institutes. Try to use these employees to perform any tasks that do not specifically require a test engineer's level of expertise. Since they are a relatively inexpensive resource, you might be successful in adding two or three such employees to your staff, when management would be inclined to deny you an additional test engineer.
Automation. The more automated the test system, the less time it takes to run the tests. Automation also allows unattended test execution overnight and over weekends, which maximizes utilization of the system under test and other resources, leaving more time for engineers and technicians to analyze and report test failures. You should apply a careful balance, however. Generating a good automated test case can take many more hours than writing a good manual test case. If you don't have the running room to thoroughly develop automated test cases before test execution begins, you should focus on automating a few simple tools that will make manual testing go more quickly.
Good Test System Architecture. Spending time in advance understanding how the test system should work, selecting the right tools, ensuring the compatibility and logical structure of all the components, and designing for subsequent maintainability really pay off once test execution starts. The more elegant the test system, the more easily testers can use it.
A Clearly Defined Test-to-Development Hand-Off Process. Two closely related activities, bug isolation and debugging, occur on opposite sides of the fence between test and development. On the one hand, test managers must ensure that test engineers and technicians thoroughly isolate every bug they find and write up those isolation steps in the bug report. Development managers, on the other hand, must ensure that their staff does not try to involve test engineers and technicians, who have other responsibilities, in debugging activities.
A Clearly Defined Development-to-Test Hand-Off Process. The project team must manage the release of new hardware and software revisions to the test group. As part of this process, the following conditions should be met:
- All software is under revision control.
- All test builds come from revision-controlled code.
- Consistent, clear release naming nomenclatures exist for each major system.
- A regular, planned release schedule exists and is followed.
- A well-understood, correct integration strategy is developed and followed during the test planning stages.
A Clearly Defined System Under Test. If the test team receives clear requirements and specifications while developing tests and clear documentation while running tests, it can perform both tasks more effectively. Being told how the product is expected to behave means that you don't have to waste time trying to guess-or dealing with the consequences of guessing incorrectly. (See the preceding section, "Testing in the Dark: Should You Proceed Without Documentation?" for tips on trying to operate without clear documentation.)
Continuous Test Execution. Related to, and enabled by, test automation, this type of execution involves setting up tests so that the system under test runs as nearly continuously as possible. This arrangement can entail some odd hours for the test staff, especially test technicians, so everyone on the test team should have access to all appropriate areas of the test lab.
Adding Test Engineers. Fred Brooks once observed that "adding more people to a late software project makes it later," a statement that has become known as Brooks's Law. This law does not hold true as strongly in testing as it does in most areas of software and hardware engineering, however. Brooks reasoned that as you add people to a project, you increase the communication overhead, burden the current development engineers with training the new engineers, and don't usually get the new engineers up to speed soon enough to do much good. In contrast, a well-architected behavioral test system reflects the (ideally) simpler external interfaces of the system under test, not its internal complexities, which means that a new engineer will be able to contribute within a couple of weeks of joining the team. (Structural test systems, in contrast, do require an understanding of system internals.) If a schedule crisis looms six weeks or more in your future, you can bring in a new test engineer in time to help. I have added test engineers on the day system testing started, and I once joined a laptop development project as the test manager about two weeks before the start of this phase. In both cases, the results were good. (There's no doubt, of course, that testing proceeds most smoothly when you have an appropriate level of staffing from the beginning. But that shouldn't stop you from adding more staff when necessary.)...