Test cases for pagination
Updated 2026-11-13 · 6 min read
These 30 cases use explicit test fixtures and checkable outcomes. Cover normal behavior, boundaries, recovery, security and usability, then adapt the requirements to your product.
How to answer in an interview
Ask whether the list uses numbered pages, offsets or cursors, whether totals are exact, and what happens when records change. Then explain traversal, boundaries and recovery before discussing visual controls. A good first example is proving that every seeded record appears exactly once across a stable list.
Scope and test data
These 30 cases assume numbered pages, a default size of 10, selectable sizes of 10 and 25, and 23 fake records named Item 01 through Item 23. Sort by a fixed unique ID ascending. The example contract resets to page 1 after filtering or changing size, and clamps an out-of-range page to the last available page. Invalid syntax is rejected. These are chosen requirements, not rules that every API follows.
Use a frozen dataset for duplicate/missing-record assertions. Test concurrent inserts separately: offset pagination can shift records when the underlying list changes, so a snapshot or cursor contract needs its own expected sequence.
These are proposed manual test cases, not an execution report. Run security and load checks only in an authorised isolated environment. Record agreed limits before execution; a case without its required limit is not ready to pass or fail.
Traversal and boundaries
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P01 | Functional | Open the initial list | Items 01–10 appear; current page is 1 and total is 23 |
| P02 | Functional | Choose Next once | Items 11–20 appear; current page becomes 2 |
| P03 | Functional | Choose Previous from page 2 | Items 01–10 return in their original order |
| P04 | Functional | Choose page 3 directly | Only Items 21–23 appear; range reads 21–23 of 23 |
| P05 | Boundary | Inspect Previous on page 1 and Next on page 3 | Unavailable actions cannot request page 0 or page 4 |
| P06 | Functional | Traverse all pages and collect IDs | Exactly 23 distinct IDs appear, with none missing |
| P07 | Boundary | Repeat with an empty dataset | Empty state appears with no active Next or Previous action |
| P08 | Boundary | Repeat with one record | One record appears on page 1 with no next page |
| P09 | Boundary | Repeat with exactly 10 records | One full page appears; no phantom empty page follows |
| P10 | Boundary | Repeat with 11 records | Page 2 contains exactly the eleventh record |
State, invalid requests and recovery
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P11 | Functional | Switch page size to 25 while on page 2 | Page resets to 1 and all 23 records appear |
| P12 | Functional | Apply a filter matching three records from page 3 | Page resets to 1 and count is 3 |
| P13 | Functional | Change sort while on a later page | Page resets to 1; the requested ordering covers the whole dataset |
| P14 | Functional | Refresh a valid page-2 URL | Page 2 and the selected size, sort and filters are restored |
| P15 | Functional | Open a detail view from page 2 and use Back | Page 2 returns with the same filters and selected size |
| P16 | Negative | Request page 0, a negative page or a fractional page | Validation identifies the invalid page; no arbitrary offset is queried |
| P17 | Negative | Request a nonnumeric page or unsupported size | Request is rejected with a controlled validation response |
| P18 | Boundary | Request page 99 with the 23-record fixture | Page 3 is shown and the URL and current-page indicator agree |
| P19 | Functional | Delete all three records on page 3, then reload | List moves to page 2 and reports 20 records |
| P20 | Negative | Fail the page-2 request, then retry | Failure is visible; retry loads page 2 without duplicating rows |
Race conditions, accessibility and operational checks
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P21 | Functional | Delay page 2, request page 3, then release page 2 | Page 3 remains selected; the stale response cannot replace its rows |
| P22 | Functional | Click Next repeatedly while loading | Final selected page matches its rows; no mixed-page append occurs |
| P23 | Security | Request another tenant's records through a modified list URL | No IDs, counts or rows from the other tenant are returned |
| P24 | Security | Insert markup-like text in a page parameter | Validation renders it safely; no script runs |
| P25 | UI | Traverse controls with keyboard only | Focus is visible; available pages activate without a mouse |
| P26 | UI | Inspect current-page and navigation names with a screen reader | Current page and each navigation destination can be distinguished |
| P27 | UI | Load a new page with a screen reader active | Completion or result-count status is announced without stealing focus |
| P28 | Compatibility | Run traversal on supported desktop and mobile browsers | The same 23 IDs and boundaries are obtained on each |
| P29 | Performance | Measure first and deep pages on a large seeded dataset | Both meet the recorded latency budget; measurements include page number and dataset size |
| P30 | UI | Use a narrow viewport with many page numbers | Controls remain reachable; condensed page ranges do not obscure current or last page |
Evidence and interview follow-up
Save the IDs returned by each request, its page parameters and the displayed range. A screenshot alone cannot prove that page 2 has not repeated page 1. Do not equate a fast first page with a fast deep page; measure both against an agreed budget.
If asked “What if a record arrives while I browse?”, explain that the expected result depends on snapshot versus live-list semantics. Agree on that before logging duplicates caused by live inserts as defects.
Downloads
Quick answers
Does every paginated list need a total count?
No. Cursor-based lists may offer only a next-page token. Replace exact-count assertions with continuation and end-of-list checks.
Which pagination cases should be smoke tests?
Initial page, next and previous, last partial page, empty results, and filter reset catch different failure modes quickly.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.