Many teams' daily testing gets broken down into numbers. If you're used to dashboards, it can be easy to forget the prime objective: to raise up quality issues—or, in the case of safety-critical devices, potential hazards. Graphs are comfortable, but do they really provide the information we should be looking for?

When an agile team talks about velocity, it's usually how much functionality they'll deliver in a sprint, often based on historical data about the number of story points the team tends to finish. But you shouldn't use velocity as a measure of success for your agile process. Make sure everyone knows what's important.

We use test design techniques to answer the questions “What do I need to test?” and “What tests should I perform?” We try to ensure test coverage during test automation too, except that choosing poorly creates slower builds and unreliable information about product quality. Here are some guidelines for test selection.