When you’re designing a dashboard to track and display metrics, it is important to consider the needs and expectations of the users of the dashboard and the information that is available. There are several aspects to consider when creating a new dashboard in order to make it a useful tool. For a mnemonic device to help you easily remember the qualities that make a good dashboard, just remember the acronym “VITAL.”
One key benefit of metrics is that they can be measured using a standard process; we can explain the numbers, and leadership can understand what that means. The downside is that it is only a measurement, so issues can easily hide until they become problems, and great work can also go unrepresented. Sporting events are a great example: The end score tells you who won, but not the details of the game. We need to look deeper.
There are many metrics to measure the effectiveness of a testing team. One is the rejected defect ratio, or the number of rejected bug reports divided by the total submitted bug reports. You may think you want zero rejected bugs, but there are several reasons that’s not the case. Let's look at types of rejected bugs, see how they contribute to the rejected defect ratio, and explore the right ratio for your team.
This article explains methods to build a team that will embrace "required work" and deliver robust software in a predictable fashion. It proposes a measure that helps calculate the throughput of an agile team by comparing work committed to work actually done.
Observing customers in a usability lab can be invaluable for improving product design. But, once your software leaves the lab, do you know what your customers are actually doing and whether or not your software meets their expectations? Learn how engineers on the Microsoft Office team apply a variety of software telemetry techniques to understand real-world usage, how the results drive product improvements, and how you can apply similar techniques.
Managers often use metrics to help make decisions about the state of the product or the quality of the work done by the test group. Yet, measurements derived from bug counts can be highly misleading because a "bug" isn't a tangible, countable thing; it's a label for some aspect of some relationship between some person and some product, and it's influenced by when and how we count ... and who is doing the counting.
People often point to requirements documents and process manuals as ways to guide a new tester. Research into knowledge transfer, as described in The Social Life of Information, suggests that there is much more to the process of learning. Michael Bolton describes his own experiences on a new project, noting how the documentation helped ... and didn't.
In this interview, Larry Maccherone, the director of analytics and research at AgileCraft, explains how you can better use data within your software team. He digs into metrics and measurements within an agile environment and how to determine what data is valuable.
In this interview, TechWell's Mike Sowers goes in depth on the measurements, metrics, and management side of testing. He discusses both the good and the bad on his test automation journey in large and small enterprises and communicates the real challenges.
In this interview, Annette Ash, a coach and trainer with SolutionsIQ, talks about the dirty term in the room: quality metrics. She reveals whether tracking metrics is beneficial, what it accomplishes, and what should be tracked with regards to software quality.
In this interview, TechWell CIO and consultant Mike Sowers details key metrics that test managers employ to determine software quality, how to know a piece of software's readiness, and guidelines for developing a successful test measurement program.
Ashwin Desai has faced the daunting challenge of using measurements and metrics to assess and improve product quality through process change. Join him as he shares what he learned on the journey to move the sports technology firm Hudl from a reactive approach to quality to quantitative, data driven, proactive means to improve product quality. Just as Hudl itself provides the ability for coaches and teams to analyze and improve their performance based on data, they wanted to move the teams building Hudl to use the same approach to improve quality. Ashwin shares how they selected measurements, the work agile teams completed to get buy-in for the measurements, and how the data was normalized to provide understanding of the quality of each initiative and the variance between them.
When software development teams work in waterfall environments, traditional performance management programs can help encourage personal development and innovation. However, Tina Rusnak says that when organizations move to agile, measuring performance takes on a new form that often causes...
The Mismeasure of Software: The Last Metrics Talk You'll Ever Need to Hear Lee Copeland claims that most organizations have some kind of metrics program—and almost all are ineffective. After explaining the concept of measurement, Lee describes two key reasons for these almost universal...