📊 Dashboards & QA Metrics

Dashboards & QA Metrics: Picture a car dashboard: speed, revs, fuel, engine temperature. None of them alone answers "is the car fine" -- high speed may mean you are driving well

Picture a car dashboard: speed, revs, fuel, engine temperature. None of them alone answers "is the car fine" -- high speed may mean you are driving well or that you are about to miss the corner. A gauge takes its meaning from context. The question worth pausing on: if the burndown chart runs as a flat line, is the team lazy? The answer may well be no: scope may have been added mid-sprint, a dependency may have been blocking, or work may be piling in the verification queue rather than in Done. A chart shows the event, not its cause. Compare: a suite with ninety percent code coverage looks healthy, yet that number is reachable with tests that contain no assertion at all. When the thing you measure and the thing you care about drift apart, the number can rise while quality falls. This is the most dangerous point for QA: the moment "number of bugs closed" becomes a performance target, behavior distorts -- records get split, small issues are filed separately, and debatable bugs are closed as "cannot reproduce". A measure stops being a good measure the moment it becomes a target. In this tab you will learn to read the metrics and to see how they get gamed.

🧭 What You Will Learn in This Tab

We will cover the filter to gadget to dashboard chain; what burndown and velocity charts do and do not tell you; how a QA bottleneck appears in a control chart and a cumulative flow diagram; the formulas for defect density, defect leakage, reopen rate and bug age and the query behind each; and how a metric distorts once it becomes a target.

1️⃣ K1. The Filter to Gadget to Dashboard Chain

A dashboard gadget is the VISUALIZED form of a query you learned on the JQL tab -- a saved filter is chosen, and the gadget turns that filter's result into a number, bar chart or pie chart. The chain is always the same: JQL is written first, then saved, then a gadget CONNECTS to that saved filter.

A gadget shows a number that looks wrong. What is the most correct first diagnostic step?

Delete the gadget from the dashboard and re-add it

Open the saved filter the gadget is connected to and run its JQL in the search box

Delete the entire dashboard

A gadget only shows the result of the JQL UNDER it -- if the number is wrong, the problem is almost always in the query itself (a wrong condition, a wrong project). Verifying the chain at its source (the JQL) diagnoses far faster than deleting and re-adding the gadget.

In which order are the three links of the chain built?

JQL is written first, then saved, then a gadget is connected

A gadget is added first, then JQL is auto-generated

The order does not matter