Managing The Testing Process

Managing The Testing Process

by Rex Black
     
 

This new addition to the Best Practices series describes an integrated approach to managing the computer testing process. While other books on testing focus primarily n the act of testing code, this title addresses both software and hardware issues—with proven techniques to ensure overall project quality. The CD-ROM includes forms and templates for Excel and

Overview

This new addition to the Best Practices series describes an integrated approach to managing the computer testing process. While other books on testing focus primarily n the act of testing code, this title addresses both software and hardware issues—with proven techniques to ensure overall project quality. The CD-ROM includes forms and templates for Excel and Access.

Product Details

ISBN-13:
9780735605848
Publisher:
Microsoft Press
Publication date:
06/09/1999
Pages:
350
Product dimensions:
7.41(w) x 9.52(h) x 1.31(d)

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.

GAS PEDALS

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.)...

Meet the Author

With a quarter-century of software and systems engineering experience, Rex Black is President of RBCS (www.rbcs-us.com), a leader in software, hardware, and systems testing. For over a dozen years, RBCS has delivered services in consulting, outsourcing, and training for software and hardware testing. Employing the industry ™s most experienced and recognized consultants, RBCS conducts product testing; builds and improves testing groups; and hires testing staff for hundreds of clients worldwide. Ranging from Fortune 20 companies to start-ups, RBCS ™s clients save time and money through improved product development, decreased tech support calls, improved corporate reputation, and more.

As the leader of RBCS, Rex is the most prolific author practicing in the field of software testing today. His popular first book, Managing the Testing Process, has sold over 30,000 copies around the world, including Japanese, Chinese, and Indian releases. His three other books on testing, Critical Testing Processes, Foundations of Software Testing, and Pragmatic Software Testing, have also sold tens of thousands of copies, including Hebrew, Indian, Chinese, Japanese and Russian editions. He has written over twenty-five articles, presented hundreds of papers, workshops, and seminars, and given about thirty keynote speeches at conferences and events around the world. Rex is the President of both the International Software Testing Qualifications Board (ISTQB) and the American Software Testing Qualifications Board (ASTQB).

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >