In modern motor racing, such as formula one, each car is wired with a multitude of sensors that detect almost every possible influence or reaction on the racing car that it is possible to measure. Ride height, suspension travel, wheel spin, steering input and many other measurements all get recorded and analyzed in an effort to squeeze some more performance out of the race car. During a race engineers will monitor the engine performance and fuel consumption in real-time to help the tactical decisions that are made during a race, or slow the car down to avoid an impending engine failure. After the race is long over the data is analyzed to help tune the setup of future events and help evolve the car in an effort to win future races.

Software development can benefit in exactly the same way from this type of analysis and monitoring. Unlike a race car it isn’t necessary to purchase specialised measuring equipment to record data, as it is mostly already being recorded. However, like the racing counterpart it is necessary to spend some effort to yield some useable information and valuable results.

One of the most valuable tools that is available to a Software Development team are the statistics and metrics that can be recorded during a project, as it progresses, or in a post mortem at the end of a project. These different types of measures provide tactical and strategic benefits to an organization during a project. Tactical metrics are produced at a regular interval throughout the life of a project, (usually daily) and provide a close to real-time view into the health of a project.

Tactical metrics are typically produced by the test manager and include the defect trend graph, The defect trend is the single most valuable indicator that I use on my projects, it is the closest thing to an electrocardiogram (ECG) that I have seen for a software project. This graph plots active defects over the life of the project and provides one of the most valuable insights into the progress of both the testing system and the quality of the product itself.

So what exactly is an active defect? An Active defect is any defect that has not been closed, regardless of where it is in the defect cycle. For example, if a fix has been completed and is ready to be verified by a tester, is still counted as an active defect.

Other graphs that are quite valuable include reports that identify the most unstable components in the system, and test execution reports that indicate the amount of test coverage.

Another key graph is the “worm”, which shows daily how you are actually progressing compared to the original plan.