Zero, one, many, too many: testing the four data states

You open the Projects page on https://staging.example.com with your usual test account. Twelve projects, tidy cards, everything fine. Two days later a real customer signs up, lands on the same page with no projects at all, and sees a spinner that never stops. The console shows TypeError: Cannot read properties of undefined (reading 'length').

Nothing was broken. The page had simply never been opened with zero rows in it.

Short version

Every list, table, chart, and dashboard has four data states: zero, one, many, and too many.
Most teams test only "many", because that is what the demo account contains.
Zero breaks the code. One breaks the layout. Too many breaks the performance.
Create each state on purpose with seed data, which means test records you add before testing.
Add all four states to your checklist for any screen that shows a list.

The four states at a glance

State	What to check	The classic bug
Zero	Empty message, no crash, working action button	Endless spinner, or `Cannot read properties of undefined`
One	Layout with a single item, singular wording	"1 items", a card stretched across the full row
Many	Pagination, sorting, filtering, selection	Sorting only sorts the visible page
Too many	Load time, export, search, long text	Browser freezes, export times out, header text overflows

Zero: empty state testing

An empty state is the screen a user sees when there is no data to show. Empty state testing is the practice of checking that screen on purpose, instead of hoping nobody ever reaches it.

Zero is the most common state in a product and the least tested one. Every user starts here. Every filter can land here. Every list becomes empty when someone deletes the last item.

The four ways a screen goes empty

A brand new account. Sign up as a fresh user, not your seeded one.
A filter that matches nothing. Set the status filter to "Archived" on an account with no archived records.
A search with no results. Search for zzzqqq in the customer list.
The last item deleted. Delete rows one by one until none are left, and stay on the page.

That fourth case is the one teams miss. The page was fine when it loaded with three rows. It only breaks when the count drops to zero without a reload.

What to check

The screen says something useful, such as "No projects yet — create your first one", not a blank white area.
There is a clear next action. An empty list with no button is a dead end.
The spinner stops. A "0 results" message and a stuck loading spinner look completely different to a user, but they are easy to confuse in code. If the spinner never turns into a message, that is a bug.
Charts render. A bar chart with no bars should show axes and a note, not a broken box or a chart drawn with negative height.
Averages do not divide by zero. An average is total divided by count, so a count of zero can produce NaN (Not a Number), Infinity, or a crash. Look for "Average order value: NaN" on the dashboard.
The console is clean. Cannot read properties of undefined (reading 'length') almost always means the code expected an array and got nothing.

Seed recipe for zero

Sign up a new account as [email protected] on https://staging.example.com.
Do not run any onboarding wizard or demo data import.
Open every main screen in turn: dashboard, projects, reports, team, billing history.
Then log in as [email protected], open a list with data, and delete every row while staying on the page.

One: single-item layouts

One item sounds harmless. It is where layouts fall apart, because designers usually draw three cards or five rows, and the code stretches to fill the space.

What breaks with exactly one

Carousels. A carousel is a slider that rotates through several panels. With one slide, the arrows may still appear and scroll to an empty area, or the auto-rotation may flicker as it loops back to the same slide.
Pluralisation. Pluralisation is choosing between singular and plural wording. "1 items selected" and "1 results found" are the giveaway. Check counters, tab labels, toast messages, and confirmation dialogs.
Grids. A grid set to stretch will make one card fill the entire row. A card designed at 320px wide looks broken at 1200px, with a tiny image and a huge white gap.
Percentage bars. With one record, that record is 100% of the total. A progress bar or a pie chart showing a single full ring is often correct but rarely reviewed, so check that the label matches.
Comparisons. "Compared to last period" needs two data points. With one, some dashboards show +Infinity% or an empty arrow.

Seed recipe for one

Log in as [email protected].
Create a single project named "Solo Project".
Add exactly one task, one comment, and one attachment inside it.
Open the list view, the card view, and any summary widget on the dashboard.
Select the one item and read the selection counter word for word.

Many: the state you already test

"Many" is the normal load — enough records that the screen behaves like a real account. This is the state your demo data already gives you, so the risk here is different. The screen looks right, but the controls that manage the data are wrong.

What to check

Pagination. Pagination is splitting a long list across numbered pages. Check the first page, the last page, and a page in the middle. Then check page 3 of a filtered list, because filters often reset the page number and leave you on an empty page 3 of a 1-page result.
Sorting across pages. Sort by "Created date" and note the last row on page 1 and the first row on page 2. If the order does not continue, the sort is being applied only to the visible page.
Filter plus pagination together. Apply a filter while on page 4. Most products should send you back to page 1. Many do not.
Select all. This is the most frequent bug in this state. Tick the header checkbox on a list of 250 rows showing 25 per page, then look at the counter. If it says "25 selected" but the button says "Delete all", you have found a serious one.
Counts. The total shown at the top should match the number of rows across all pages, not the rows on screen.

Seed recipe for many

Log in as [email protected].
Create 120 records so you get several pages at a typical page size of 25.
Give them mixed values: different owners, dates spread over six months, and a mix of statuses so filters return partial results.
Include a few records that sort oddly on purpose, such as names starting with a number, a lowercase letter, and an accented character.

Too many: where things break slowly

"Too many" is the state a growing customer reaches on a Tuesday afternoon, months after release. Nothing fails at once. Things just get slower until they stop.

What to check

Large tables. Load a table with 10,000 rows. Time it. If the tab stops responding to clicks or scrolling for more than a second or two, the page is rendering every row instead of only the visible ones.
Exports. Ask for a CSV export, which is a plain text file of the whole data set. Watch for a request that never finishes or returns a 504 Gateway Timeout.
Search. Type in the search box on a large data set and watch the response time. Search that scans everything on each keystroke will lag badly at scale.
Long text. Set a team name to 40 characters, such as "Northern Regional Operations And Support". Check the header, the sidebar, the breadcrumb, and the account switcher. Long names either wrap, push other elements off screen, or overlap.
Deep nesting. Give one user 200 projects. Check the project dropdown, the sidebar list, and any place that loads all projects at once to build a menu.

Seed recipe for too many

Ask a developer for a script that inserts 10,000 rows against [email protected], or use the API with a loop.
Rename the workspace to a 40-character name.
Create 200 projects under one user.
Repeat your normal flows and record the timings, because "it feels slow" is not a reportable number.

For this state especially, capture the console and network activity while it happens, since the evidence disappears the moment you reload. A tool like Crosscheck records console logs, network requests, and environment details from the page as you report the bug, so a slow export or a frozen tab arrives with the timings already attached.

Frequently asked questions

Do I need all four states for every screen? Use all four for any screen that shows a list, table, chart, or counter. A static settings form with fixed fields does not need them.

Where does "too many" start? Pick a number that your largest customer could reach in two years, then double it. For most lists, 10,000 rows is a fair target.

Is empty state testing really a bug source, or just a design detail? Both. A missing empty message is a design issue, but Cannot read properties of undefined on an empty list is a crash that blocks every new user.

How do I create these states without a developer? Use the product itself for zero and one, and the API or a bulk import for many and too many. Ask once for a seed script and you can reuse it forever.

Should I file one bug for all four states? File one bug per state, because they usually have different causes and different owners. Link them together so the team can see the pattern.