Many consider metrics a thorn in the side of software test and development efforts. However, when used properly, metrics offer critical insight into underlying issues within projects. In addition, metrics can provide vital real-time information for strategic and tactical project adjustments. Based on his experiences during a major acceptance test project within a lengthy ERP implementation, Shaun Bradshaw demonstrates how an optimal set of test metrics steered the effort toward success. Shaun shares key metrics to track progress and test coverage that enabled their test and management decisions and describes ways these same metrics can benefit your organization. Learn how to implement these valuable indicators and how to relay this information up the management chain in easily comprehensible forms. Take home a set of valuable metrics you can implement quickly to give yourself the upper hand in future testing efforts.
Gathering and presenting clear information about quality-both product and process-may be the most important part of the test manager's job. Join Lloyd Roden as he challenges your current progress reports-probably full of lots of difficult-to-understand numbers-and asks you to replace the reports with a custom Test Manager's Dashboard containing a series of graphs and charts with clear visual displays. Your dashboard needs to report quality and progress status that is accurate, useful, easily understood, predictive, and relevant. Learn about Lloyd's favorite dashboard graphs-test efficiency, risk progress, quality targets, and specific measures of the test team's well being. Learn to correlate and interpret the various types of dashboard data to reveal the complete picture of the project and test progress.
In their drive to delight customers, organizations initiate testing and quality improvement programs and define metrics to measure their success. In many cases, we see organizations declare success even though their customers do not see much improvement in either products of services. Wenje Lai and J.P. Chen share their approach of identifying quality improvement needs and defining the appropriate metrics that link improvement goals to customer experiences. As a result, the resources allocated to internal quality improvement efforts maximize the value to the business. Their approach is a simple three-step procedure that any test or development organization can easily adopt. It starts with using customer survey data to understand the organization’s customer pain points and ends with identifying the metrics that are linked to the customer experience and actionable by development and test teams inside the organization.
Managers often fall into the trap of making sure that everyone is busy. It seems logical that we should keep all of our highly paid “resources” (ouch!) fully utilized. Surprisingly, optimizing for maximum utilization (busyness) actually creates less business value. Not surprisingly, it also can lead to quality problems, lowered job satisfaction, and even burnout. Join Chris Sims for this experiential session about the Theory of Constraints in which we explore better ways of optimizing how teams work. We will launch a fictitious aerospace company, build airplanes (albeit paper ones), and track our financial results. We'll apply the “Five Focusing Steps” from the Theory of Constraints: identify, exploit, subordinate, elevate, and repeat. We'll devise a process to evolve and improve our efficiency, our satisfaction in a job well done, and, ultimately, our profitability.
Software quality often gets lots of lip service and little else-until its absence triggers a disaster and stuff hits the wall. Don Beckett shares work he did to determine when the software for a satellite destined to orbit the earth was sufficiently stable to risk being launched. Failure would have cost hundreds of millions of dollars. Don shows how he modeled this problem to answer the “launch/don't launch” question. Beginning with an analysis of the factors that determine acceptable quality and the issues that confront defect collection, Don overviews how defect discovery follows a Rayleigh curve distribution that anyone can use for predicting defects remaining in a system. He shares a model of how staffing and scheduling trade-offs will almost certainly impact defect creation rates.
Measurement problems in software organizations are many: challenges with effort tracking; difficulties motivating the workforce to comply; resource management in multitasking and matrix organizations; attempts to "standardize" project status reporting or dashboards that run amuck; the misconceptions that fester and hinder defect collection and analysis throughout the life cycle; and management’s failure to truly understand and actually use measurement data and information to make decisions. Beth Layman reviews these thorny and recurring measurement problems-problems that plague even those organizations with established measurement cultures. She provides case studies of the problems and discusses their typical root causes. Beth concludes with practical advice on what it takes to institutionalize valuable, workable measurement practices within your organization.
By its very nature, the endgame of software projects is a hostile environment. Typical dynamics include tremendous release pressure, continual bug and requirement discovery, exhausted development teams, frenzied project managers, and “crunch mode” for testers. However, hope and relief are available. By using metrics derived from defect discovery and repair patterns, you can learn how to guide projects toward a successful release with less stress and more certainty. Bob Galen shares patterns that you can mine from your defect metrics to focus your entire team on a few key performance indicators. Examine defect patterns, maturation rates, and other organizationally unique patterns that you can leverage as project milestones. Learn about the Pareto Principle and its implications on defect actions and workflow. Next time, you’ll be better prepared for your project endgame and increase the likelihood of an on-time delivery.
Even though the code may have been written only five years ago, there it is-a sprawling unintelligible mess that nobody wants to touch. For most people and teams, this reality is a cause for fear and loathing-something we want to sweep under the rug. We can, however, choose to see “bad” code as a challenge to restructure and refactor into a maintainable design that serves the business for years to come. Although legacy code presents many constraints on design choices, it offers the opportunity for incremental improvement. Michael Feathers shows you how to practice design within the boundaries of what some see as unintelligible code and explains ways to make the improvement process manageable. See how you can escape the fear that holds you back from productive action. Find out how to start with what you have now and progress toward a structure that supports the work at hand and immediately adds value.
Every organization has its own project patterns. Some management teams take a long time to start a project. Others interrupt and divert the project teams once they've started. Some project teams never finish because the product must be “perfect.” Still others believe there is a single solution to all their problems such as “Two weeks of overtime and we'll be caught up!”, or “If the testers just tested more”, or “We just need some more time designing.” Project managers also fall into patterns: overly optimistic, pessimistic, risk-encouraging, risk averse, etc. Johanna Rothman explores different project and management patterns to help you understand which patterns are working-and which are harmful-for you.
Perhaps the most sought after and least understood metric in software testing is the ratio of testers to developers. Many people are interested in learning the standard industry ratio so that they can determine the proper size of their test organization. Randy Rice presents the results of his recent research on this metric and explores the wide range of tester-developer ratios in organizations worldwide. Learn why this metric is almost always not the best way to determine your test organization’s staffing levels and how to understand and apply this metric in more helpful ways. Find out how different tester-developer ratios relate to test effectiveness. Take away a new appreciation of your own tester-developer ratio and ways to meaningfully convey this metric to management to help rightsize your test team and improve the ROI of testing. Determine the "right ratio" of testers to developers in your team and company.