Dashboard test cases, for the number that is wrong but plausible

Dashboards fail differently from the rest of an application. A broken screen gets a support ticket within minutes; a wrong number gets acted on. Nobody can tell by looking whether revenue for last month should be that figure, so the only test that establishes correctness is reconciliation against the underlying records with a hand calculated expectation. Everything else confirms that the widget is stable, which is not the same thing. The second most valuable case is cross widget consistency, because two panels reporting the same measure from different queries will diverge, and that divergence is the thing users do notice and the thing that discredits the whole page.

Time is where aggregation quietly goes wrong. A day boundary depends on a timezone, and if that timezone is the viewer device rather than a documented reporting timezone, two people looking at the same dashboard see different numbers and both are convinced the other is mistaken. Ranges need consistent inclusivity so a record at the boundary is counted in exactly one period, and period comparisons need to state their span, because a month over month change across February and March is comparing twenty eight days with thirty one.

Empty and zero are different states and rendering them the same way causes real damage. A period where the pipeline has not reported yet is not a period with no activity, and showing it as zero turns a delayed job into an apparent business collapse. The related case is the honest freshness indicator: an as at time that reflects page load rather than the data behind it is worse than no indicator, because it actively asserts that stale figures are current.

Finally, aggregates leak. Row level permissions applied to a detail view but not to a summary let a restricted user infer the values they were not allowed to see, and narrowing a filter until a group contains one record turns a permitted aggregate into an individual disclosure. The widget data endpoint needs its own authorisation rather than trusting the page that renders it, and the export path needs the same filters and the same permissions as the screen, plus neutralisation of any cell starting with an equals sign so a downloaded file cannot execute formulas in the recipient spreadsheet.