Mac dashboard QA checklist: data, color, and load

The short answer: approve a Mac dashboard only after five proofs agree. Record the report and filter state, capture the exact rendered view, map important colors to their roles, repeat one representative action while recording load, and save the decision with its evidence. A screenshot, a hex value, or a low CPU reading cannot prove the other layers.

This checklist is for analytics dashboards, client reports, internal KPI screens, status boards, and browser-based product metrics. It starts after the source data has passed review. It does not validate queries, business definitions, or the dashboard application's calculations.

Disclosure: I build TeenyApps, including TeenyColor for local rendered-color observations and TeenyStat for aggregate system-load context. My bias is toward small native Mac utilities. Apple's Screenshot app, Digital Color Meter, and Activity Monitor remain the baseline when they provide the evidence you need.

Use the paired TeenyColor guide to check dashboard chart colors on Mac without confusing a rendered sample with a source token or formal contrast result. Use the paired TeenyStat guide for a slow Mac dashboard in the browser when you need a baseline, action, and recovery record before opening Activity Monitor.

Use the Mac data review checklist first when the source CSV, import, or conversion is still uncertain. Use the bug report checklist when the outcome is a defect report rather than approval.

Dashboard QA decision table

01Freeze the dashboard state before sampling anything

Dashboard QA starts with identity. Record the dashboard name, URL or report ID, workspace or account, date range, timezone, comparison period, segment, visible and hidden filters, data refresh time, and dashboard build or revision when the product exposes one.

Keep data correctness separate from render acceptance. A chart can render exactly as configured while its query, metric definition, or source export is wrong. If the source is still under review, use the Mac data review checklist first and attach that result. This pass proves the review state, not the underlying calculation.

Reload once, return to the recorded state, and confirm that the same filters and values reappear. If a scheduled refresh changes the data during review, start a new record instead of combining evidence from two states.

02Capture the exact view that will be reviewed

Use Apple's Screenshot app for the evidence file. Capture the full browser window when filters, legends, the browser, or a refresh timestamp establish context. Use a selected portion for one chart or tooltip only when a wider companion capture preserves its identity.

Record the filename, capture time, macOS appearance, browser and version, page zoom, display, and whether the file is a full window or crop. Record the capture format or color profile when color is part of the decision. Do not sample from a compressed chat preview or a document thumbnail.

A screenshot is rendered evidence. It is not the dashboard source, a browser trace, or proof that another display rendered the same pixels. If the page contains customer names, internal revenue, or unreleased product data, sanitize the copy that leaves the Mac and keep the original evidence in its approved location.

03Sample chart colors from the rendered dashboard

Build a color-role map instead of a loose palette. For each important sample, record the chart role, state, exact region, rendered value, intended source value when known, and whether the two agree. Useful roles include actual series, forecast series, warning badge, selected segment, grid line, axis label, and tooltip background.

TeenyColor uses Apple's NSColorSampler and converts the returned sample to sRGB when possible. Its history, names, pins, and export can preserve a small local observation set. That sRGB record is not the original CSS or design token, and it does not preserve a raw HDR or EDR value.

Sample a stable interior region and record the aperture or region used. Avoid anti-aliased text edges, shadows, transparency boundaries, hover animations, and blended chart edges unless that blend is the subject of the review. Apple's Digital Color Meter is a useful built-in alternative when you need its aperture and color-space controls.

If success, warning, selected, and disabled states differ only by color, record a second cue such as text, icon shape, pattern, or label. The sample confirms a rendered observation. The state model still needs to make sense without the hue.

04Choose the contrast rule before calculating

Classify the element first. WCAG 2.2 Success Criterion 1.4.3 covers text and images of text at Level AA. It uses 4.5:1 for normal text and 3:1 for large-scale text. Success Criterion 1.4.11 covers the visual information needed to identify active user-interface components and meaningful graphical objects, with a 3:1 requirement against adjacent colors.

Use the owned source foreground and background values for a formal calculation when they are available. Rendered screenshot samples are observation evidence; anti-aliasing, blending, transparency, display processing, and capture conversion can change individual pixels. Keep those observations, but do not label them as source-token conformance proof.

TeenyColor's quick badges compare one sampled sRGB color with white and black. They do not calculate an arbitrary foreground/background pair or decide which WCAG criterion applies. For a label on a custom card, collect both owned values and record the criterion, text classification, full unrounded ratio, result, and rendered screenshot.

05Watch CPU and memory before a live dashboard review

Use a fixed sequence: let the dashboard settle, record a baseline, repeat one representative action, and watch recovery. Keep the same browser, report state, zoom, extension set, display arrangement, and observation window. Record wall-clock start and end times because a sparkline alone does not identify when the action happened.

TeenyStat reads aggregate and per-core CPU from processor-tick deltas. Its first CPU read establishes the previous sample and may be near zero. It calculates used memory as active plus wired plus compressed memory divided by physical memory. That is not Apple's Memory Pressure graph or swap measurement.

The current app supports 1, 3, 5, or 10-second collection intervals and keeps 60 points per sparkline. At the default three-second interval, a full buffer represents roughly three minutes, but a slow collection can skip an overlapping tick. Record the selected interval and do not infer exact continuous coverage from 60 points.

Open Activity Monitor when the slowdown repeats or the decision depends on a process name, CPU History, Memory Pressure, swap, network or disk activity, or whether to quit a process. Run a separate call-state pass if screen sharing is part of approval, because the meeting app adds its own load.

06Save one dashboard acceptance record

Keep the record short enough to review and complete enough to rerun. Link each decision to its evidence instead of pasting unrelated readings into one note.

A useful record includes:

1. Dashboard identity: URL or report ID, account, date range, timezone, segment, filters, refresh time, and revision.
2. Rendered evidence: screenshot filename, capture time, browser, zoom, appearance, display, format, and full-window or crop state.
3. Color-role map: role, state, sample region, rendered observation, owned source value, and comparison result.
4. Contrast decision: element type, applicable criterion, owned foreground/background values, unrounded ratio, and result.
5. Load record: interval, baseline, representative action, recovery, timestamps, and Activity Monitor attachment when needed.
6. Acceptance: approved, approved with exception, blocked, or needs new evidence, plus owner and next action.

Do not write "CPU and memory looked normal" without the workload, time, readings, and tool boundary. Do not write "colors match" without roles and source values. The acceptance record should state exactly what passed and what remains outside this review.

Sources checked

• Apple Support: Take a screenshot on Mac for full-screen, selected-portion, window, menu, and Screenshot app capture paths.
• Apple Support: Digital Color Meter User Guide for Mac for reading color values from pixels on the display.
• Apple Support: View CPU activity in Activity Monitor on Mac for CPU history, current CPU usage, and process-level CPU context.
• Apple Support: View memory usage in Activity Monitor on Mac for memory pressure and memory-use context.
• W3C WAI: Understanding Success Criterion 1.4.3 Contrast (Minimum) for text contrast thresholds.
• W3C WAI: Understanding Success Criterion 1.4.11 Non-text Contrast for active component and meaningful graphical-object boundaries.
• TeenyColor claims and limits were checked against the TeenyColor homepage and current local Swift source for NSColorSampler, sRGB conversion, local history, names, pins, export, and white/black contrast badges.
• TeenyStat claims and limits were checked against the TeenyStat homepage and current local Swift source for processor-tick CPU deltas, active plus wired plus compressed memory, 1/3/5/10-second intervals, skipped overlapping collections, 60-point buffers, and session high/low values.

Common questions

How do I QA a dashboard screenshot on Mac?

Record the report and filter state, capture the exact rendered view, map important colors to their roles, check the relevant contrast criterion, repeat one dashboard action while recording load, and save the result in one acceptance record.

Should dashboard color checks use the design file or the browser?

Use both when the decision depends on fidelity. Source tokens document intent; the browser or exported screenshot documents the rendered observation. A rendered sample does not replace the owned foreground and background values needed for a formal contrast calculation.

When should I open Activity Monitor during dashboard QA?

Open Activity Monitor when the slowdown repeats, aggregate CPU or memory stays elevated, Memory Pressure or swap matters, or the review needs a process name. A menu bar trend provides context but does not identify the responsible tab or process.