
|
|
|

STARWEST 2006 Concurrent Sessions
Go To: AGILE METHODS | EXPLORATORY TESTING | INSPECTIONS | METRICS | SECURITY TESTING |
SOA TESTING | SPECIAL TOPICS | TEST AUTOMATION | TEST MANAGEMENT | TEST TECHNIQUES
 View by Date
| Metrics |  | | Friday, October 20, 2006 10:00 AM |
Measuring the “Good” in “Good Enough Testing” Gregory Pope, Lawrence Livermore National Laboratory
 The theory of “good enough” software requires determining the trade off between delivery date (schedule), absence of defects (quality), and feature richness (functionality) to achieve a product which can meet both the customer’s needs and the organization’s expectations. This may not be the best approach for pacemakers and commercial avionics software, but it is appropriate for many commercial products. But can we quantify these factors? Gregory Pope does. Using the COQALMOII model, Halstead metrics, and defect seeding to predict defect insertion and removal rates; the Musa/Everette model to predict reliability; and MatLab for verifying functional equivalence testing, Greg evaluates both quality and functionality against schedule.
 • Review how to measure test coverage Discover the use of models to predict quality Learn what questions you should ask customers to determine “good enough” |
|  | | Friday, October 20, 2006 11:15 AM |
Measuring the End Game of a Software Project–Part Deux Mike Ennis, Savant Tecnology
 The schedule shows only a few weeks before product delivery. How do you know whether you are ready to ship? Test managers have dealt with this question for years, often without supporting data. Mike Ennis has identified six key metrics that will significantly reduce the guesswork. These metrics are percentage of tests complete, percentage of tests passed, number of open defects, defect arrival rate, code churn, and code coverage. These six metrics, taken together, provide a clear picture of your product’s status. Working with the project team, the test manager determines acceptable ranges for these metrics. Displaying them on a spider chart and observing how they change from build to build enables a more accurate assessment of the product’s readiness. Learn how you can use this process to quantify your project’s “end game”.
 • Decide what and how to measure Build commitment from others on your project Manage the end-game of your product development |
|  |
|
|