Developing a usable and consumable test-metric-reporting system is a challenge for all testing organizations. This article describes a system employable by small and large organizations and all test efforts. By using existing tools, test teams can show current progress and predict future test efforts.
Typical metrics are used to predict an outcome by comparing plans to actual results. They are objective and don't influence what you are trying to measure. Biased metrics, on the other hand, are a valuable tool for deliberately altering behavior to improve the performance of a group. Find out how biased metrics can be used on your projects to pinpoint problems in specific areas and to influence people to fix them.
Knowing how much work your group can accomplish—and how much it takes to complete that work—is critical to your success as a manager. Johanna Rothman explains how to ascertain your team's potential and how to use that information to define and manage your project portfolio so it doesn't manage you.
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.
Every change involves endings, and endings mean loss. Even the best changes mean some things will end; things that are like warm, fuzzy blankets will be taken from us. But as one thing ends, a new one begins. In this week's column, Lee Copeland assures us that new beginnings involve new understandings, new values, new attitudes, and, most importantly, a new identity for you.
The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box.
How do you know when your software is done? How do you determine which bugs need to be fixed and which can be tabled for "someday"? Robert Sabourin defines a seven-step process for establishing an effective bug triage system.