Long, long ago in a company far, far away, Bill Curtis designed one of the largest software measurement systems ever deployed. Ultimately, it reported to senior management system measures that foretold the loss of one-half of the fifth largest company on earth. Covering all of the corporation's far-flung businesses, this measurement system highlighted the four critical factors that determine a project's fate and provided categories for normalizing and classifying the company's software. It showed that many executives do not understand normal variation, and others do not want to admit what they do know. Through Bill's fascinating and sometimes bizarre story, you'll be convinced that system measurement is not only a technical undertaking but also a political one as well. In addition, you will learn about measurement standards for successful systems-standards you may be able to apply in your organization.

No one starts a project with the goal of failing, but some metrics experts claim that 80 percent of software metrics initiatives fail. Just as your software project has goals for success, you should have goals for success in your metrics initiatives. Find out what you can do to better your chance for success.

In addition to the efficiency improvements you expect from automated testing tools, you can-and should-expect them to provide valuable metrics to help manage your testing effort. By exploiting the programmability of automation tools, you can support the measurement and reporting aspects of your department. Learn how Jack Frank employs these tools with minimal effort to create test execution
status reports, coverage metrics, and other key management reports. Learn what measurement data your automation tool needs to log for later reporting. See examples of the operational reports his automation tools generate, including run/re-run/not run, pass/fail, percent complete, and percent of overall system tested. Take with you examples of senior management reports, including Jack's favorite, "My Bosses' Boss Test Status Report"-names will be changed to hide the guilty. Regardless of the

Distributed development teams, including test engineers, are becoming more the norm than the
exception. Many individual testers and test managers perform some of their job duties from
home. Test engineer Andy Roth is an extreme example of this situation-telecommuting from his
Maryland home 300 miles from his company’s office. As a “tele-tester” Andy has become a
manager in addition to his testing duties, managing his personal test lab, his time, his peer
relationships, and even managing his manager. If you are considering becoming a tele-tester,
already are one, or manage tele-testers, join Andy for a discussion of what it takes to survive and
flourish in this environment. Find out the necessary prerequisites and qualities of successful teletesters
and the tools of the trade that make life easier and most productive.

• The case for tele-testing and its limitations