Data-heavy screens: dashboards, tables, filters, forms and reports

Much of the web software a QA tests is an operational dashboard or admin console — the internal tool a business runs on: lists of transactions, users or orders, with filtering, sorting, pagination, forms to create and edit records, reports and totals, and different views per role. This is the meat of web QA for many products, and it has its own testing patterns centred on data correctness. This lesson is testing data-heavy web apps — the shape a dashboard takes.

Tables and lists: is the data right?

The core of a dashboard is usually a table of records, and the first question is always: is the data correct? Testing a data table:

Correct rows and values — does the table show the right records, with the right values in each column? Cross-check against the source (the API/database — the API-testing module) — the table can display wrong data while looking fine.
Empty state — no records: a sensible "nothing here" message, not a blank table or an error.
Large data — thousands of rows: does it stay usable and correct, or slow to a crawl / break? (Test with lots of data, not three demo rows — a common gap.)
Long/extreme values — a very long name, a huge number, a null/missing field in a cell: does the layout and formatting cope (the rendering lesson)?
Formatting — dates, currency (₹ with paise), numbers — shown correctly and consistently.

The recurring theme: a dashboard's job is to show data accurately, so a QA verifies the displayed data against the true source, at realistic scale, including the empty and extreme cases.

Filtering, sorting, searching, pagination

Dashboards let users manipulate the data view, and each control is a testing target:

Filtering — apply a filter (status = pending, date range, agent): do only the matching rows show, and all of them? Test combining filters (status and date), clearing filters, a filter matching nothing (empty result handled?), and boundary filters (the date-range edges — boundary values again).
Sorting — sort by a column ascending and descending: is the order actually correct (including numbers sorted numerically not alphabetically — "10" before "9" is a classic bug — and dates chronologically)?
Searching — does search find what it should, handle no results, partial matches, special characters?
Pagination — do the pages divide the data correctly (no rows missing or duplicated across pages)? Does the last page work? Do filter/sort combine with pagination correctly (filter, then page 2 — still only filtered rows)? Pagination + filtering interaction is a common bug spot.

The subtle bugs are in the combinations — filter and sort and paginate together — and in the correctness of the operation (a sort that is alphabetical when it should be numeric, a filter that misses edge matches, pagination that drops or duplicates rows). Test each control alone, then combined.

Forms: creating and editing records

Dashboards create and edit records via forms, and forms are where invalid input meets the system — so all the manual test-design skills apply (equivalence partitioning, boundary values, positive/negative):

Validation — required fields, formats, ranges, boundaries; does it reject bad input with a clear message, and accept valid input? (The test-design lesson's techniques, on every field.)
Submission — does it save correctly (verify at the source), show success, and update the table? Does a double-submit create duplicates (the money-flows concern, for web too)?
Editing — does editing load the existing values correctly, save the changes, and not lose fields you did not touch?
Cancel and errors — does cancelling discard changes? Does a server error on save leave a clear state, not a half-saved record?

A form on an operational dashboard often changes real data (approving a transaction, editing a user), so the correctness stakes are high — verify the record actually changed correctly at the source, not just that the UI said "saved".

Roles, permissions and reports

Two more dashboard concerns with real weight:

Roles and permissions. Different users (operator, manager, admin) should see and do different things. Test as each role: does an operator see only what they should, and is an operator prevented from admin-only actions — not just hidden in the UI, but actually blocked (an operator who edits the URL or calls the API directly must still be stopped, or it is an access bug — the security concern)? Role correctness is both functional and a security matter, and it is easy to get wrong (a button hidden but the action still reachable).
Reports and aggregates. Dashboards show totals, counts, charts, exports. These must be correct — wrong numbers on an operational dashboard drive wrong decisions. Test that a total actually equals the sum of its rows, a count matches the records, a filtered report reflects the filter, and an export matches what is on screen. Cross-check aggregates against the underlying data (compute it yourself, or query the API) — a plausible-looking wrong total is a dangerous bug because nobody double-checks it.

Check your work

Tables/lists. Verify data correctness against the source (the table can display wrong data); test the empty state, large data (thousands of rows, at scale), long/extreme/null values, and correct formatting (dates, ₹). A dashboard's job is accurate data at realistic scale.

Filter/sort/search/pagination. Filtering (only-and-all matching rows, combined filters, empty result, boundaries), sorting (actually correct — numeric not alphabetic, chronological dates), searching (no results, partial, special chars), pagination (no missing/duplicated rows, last page). The bugs are in the combinations (filter+sort+paginate) and in operation correctness.

Forms. Apply test-design techniques to every field (validation, boundaries, positive/negative); submission saves correctly (verify at source), no double-submit duplicates; editing loads and saves without losing untouched fields; cancel/error leave a clean state. Forms change real data — verify at the source.

Roles and reports. Test as each role — and confirm restricted actions are actually blocked (URL/API too), not just hidden (a security matter). Verify aggregates (totals, counts, exports) equal the underlying data — a plausible wrong total is dangerous because nobody rechecks it.

Practice

Take a data table and verify a sample of its rows/values against the source (API or database); test the empty state and with a large data set.
Test a filter thoroughly: single, combined, cleared, matching-nothing, and boundary (date-range edges); then combine filter + sort + pagination and check the result is still correct.
Test a sort on a numeric column and a date column — confirm it is numeric/chronological, not alphabetical.
Paginate a large list and confirm no rows are missing or duplicated across pages, and the last page works.
Test a create form (validation, boundaries, double-submit) and an edit form (loads existing values, saves changes, keeps untouched fields); verify the record actually changed at the source.
Test a dashboard as two different roles: confirm each sees only what it should and that a restricted action is actually blocked (try the URL/API), not just hidden. Verify a report total equals the sum of its rows.

Official documentation

MDN — Forms and validation — What to test on web forms.
OWASP — Testing for authorization / access control — Verifying role restrictions are actually enforced.
Ministry of Testing — Testing data-heavy applications — Practitioner guidance on dashboards and data.

Next: browser behaviours — back, refresh, tabs, sessions and dev tools.