QA interview guide

How would you test a dashboard?

Dashboards are easy to screenshot but hard to trust. A strong QA answer checks whether users can rely on every metric, chart, filter, export, permission rule, and freshness signal.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect metric accuracy, aggregation rules, filters, date ranges, time zones, charts, empty states, permissions, stale data, export behavior, refresh, backend consistency, accessibility, and performance.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Metrics, charts, and filters

  • Each KPI, chart, table, total, percentage, and trend matches source data rules.
  • Aggregation, rounding, deduplication, null handling, and calculated fields are correct.
  • Default date range, custom date range, timezone, fiscal calendar, and boundary dates are correct.
  • Filters, sorting, grouping, search, drill-down, reset, and refresh update all relevant widgets.
  • Empty, loading, partial data, no-access, and no-results states are understandable.

Data consistency and permissions

  • Dashboard values match backend reports, database queries, or trusted source systems.
  • Updated records appear, deleted records disappear, and stale data is clearly indicated.
  • Role, tenant, workspace, row-level permission, and restricted metric rules are enforced.
  • Drill-down pages and exports do not leak data hidden from the dashboard.
  • CSV/PDF export values match visible dashboard values and selected filters.

Backend, negative, and reliability cases

  • Invalid date ranges, huge ranges, unsupported filters, malformed query params, and empty filters are handled.
  • Backend errors, timeout, slow queries, partial widget failure, cache failure, and dependency outage are recoverable.
  • API status codes, response schema, pagination, sorting, and cache headers are verified.
  • XSS in labels, injection in filters, and sensitive values in logs are checked.
  • Concurrent data changes do not create contradictory widgets.

UX, accessibility, and performance

  • Charts have labels, legends, tooltips, accessible names, and keyboard-friendly data alternatives.
  • Screen readers can understand summary values, errors, filters, and table data.
  • Mobile layout avoids horizontal scroll and supports readable charts.
  • Large datasets, many widgets, repeated filter changes, and refresh actions meet response-time expectations.
  • Metrics, diagnostic logs, and alerts help investigate broken or slow dashboard widgets.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Each KPI, chart, table, total, percentage, and trend matches source data rules.
Aggregation, rounding, deduplication, null handling, and calculated fields are correct.
Default date range, custom date range, timezone, fiscal calendar, and boundary dates are correct.
Filters, sorting, grouping, search, drill-down, reset, and refresh update all relevant widgets.
Empty, loading, partial data, no-access, and no-results states are understandable.
Dashboard values match backend reports, database queries, or trusted source systems.
Updated records appear, deleted records disappear, and stale data is clearly indicated.
Role, tenant, workspace, row-level permission, and restricted metric rules are enforced.
Drill-down pages and exports do not leak data hidden from the dashboard.
CSV/PDF export values match visible dashboard values and selected filters.
Invalid date ranges, huge ranges, unsupported filters, malformed query params, and empty filters are handled.
Backend errors, timeout, slow queries, partial widget failure, cache failure, and dependency outage are recoverable.
API status codes, response schema, pagination, sorting, and cache headers are verified.
XSS in labels, injection in filters, and sensitive values in logs are checked.
Concurrent data changes do not create contradictory widgets.
Charts have labels, legends, tooltips, accessible names, and keyboard-friendly data alternatives.
Screen readers can understand summary values, errors, filters, and table data.
Mobile layout avoids horizontal scroll and supports readable charts.
Large datasets, many widgets, repeated filter changes, and refresh actions meet response-time expectations.
Metrics, diagnostic logs, and alerts help investigate broken or slow dashboard widgets.
Structure your answer: Start with metric correctness, default state, charts, filters, date ranges, and refresh.
Structure your answer: Add data rules: source-of-truth comparison, aggregation, rounding, stale data, and permissions.
Structure your answer: Add negative and backend cases: invalid filters, query params, timeouts, partial widget failure, and exports.
Structure your answer: Close with accessibility, mobile charts, performance with large datasets, logs, metrics, and alerts.
Do not miss: Timezone and boundary-date calculations.
Do not miss: Export data leaking hidden or restricted rows.
Do not miss: Stale data and partial widget failure.
Do not miss: Accessible alternatives for charts.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with metric correctness, default state, charts, filters, date ranges, and refresh.
  2. Add data rules: source-of-truth comparison, aggregation, rounding, stale data, and permissions.
  3. Add negative and backend cases: invalid filters, query params, timeouts, partial widget failure, and exports.
  4. Close with accessibility, mobile charts, performance with large datasets, logs, metrics, and alerts.

Common missed areas

Common missed risks

Timezone and boundary-date calculations.
Export data leaking hidden or restricted rows.
Stale data and partial widget failure.
Accessible alternatives for charts.

Answer template

Use this interview answer template

I would start with metric and chart accuracy, then cover filters, date ranges, aggregation, empty states, permissions, stale data, exports, refresh behavior, backend consistency, timezone boundaries, accessibility, mobile layout, and performance with large datasets.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test that the dashboard numbers show.”

Visible numbers are not enough. The answer misses metric accuracy, filters, date ranges, permissions, exports, stale data, backend failures, and accessibility.

Stronger answer
“I would test KPI accuracy against source data, chart values, table totals, percentages, trends, aggregation, rounding, default and custom date ranges, timezone boundaries, filters, sorting, search, grouping, drill-down, reset, refresh, CSV/PDF export, empty state, loading state, stale data indicator, updated and deleted data, role and tenant permissions, row-level access, hidden data not exported, invalid date range, malformed query params, backend timeout, partial widget failure, API schema, XSS in labels, screen reader support, keyboard navigation, mobile charts, large dataset performance, logs, metrics, and alerts.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test a dashboard?"

Start with metric correctness, default state, charts, filters, date ranges, and refresh.

Should I include negative and edge cases?

Invalid date ranges, huge ranges, unsupported filters, malformed query params, and empty filters are handled. Backend errors, timeout, slow queries, partial widget failure, cache failure, and dependency outage are recoverable.

Should I include security, API, or backend risks?

Dashboard values match backend reports, database queries, or trusted source systems. Updated records appear, deleted records disappear, and stale data is clearly indicated.

What are common missed risks?

Timezone and boundary-date calculations. Export data leaking hidden or restricted rows. Stale data and partial widget failure. Accessible alternatives for charts.

How can I practice this answer?

Use the interactive how would you test a dashboard? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario