Browse the Knowledge Hub32 resources
Test cases
Pagination test cases about stability and cost
Twenty four cases covering ordering that stays stable across pages, records inserted or deleted mid session, invalid page parameters, page size caps, deep offset performance, permission filtered totals, state restore after a detail view, infinite scroll and accessibility.
All 24 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
24 worked examples
Load the first page with default settings
TypeFunctionalPriorityHigh- Test data
- A data set larger than one page
- Expected result
- Exactly the default page size is shown, the first page is marked current, previous is disabled, and the total count matches the data set.
Navigate forward and back through pages
TypeFunctionalPriorityHigh- Test data
- Next to page three, then previous back to page one
- Expected result
- No record appears twice and none is skipped. Returning to page one shows exactly the same rows as the first load.
Jump to the first and last page
TypeFunctionalPriorityMedium- Test data
- Last page of a set that does not divide evenly
- Expected result
- The last page shows the remainder rather than a full page, and next is disabled there.
Verify ordering is stable across pages
TypeStatePriorityHigh- Test data
- A data set with many records sharing the sort value, for example the same created date
- Expected result
- A unique secondary sort key makes ordering deterministic. Without one the database may order ties differently per query, so records repeat on one page and vanish from another.
Page through while records are being inserted
TypeStatePriorityHigh- Test data
- Insert a record that sorts onto page one, then advance to page two
- Expected result
- Documented behaviour, and no record is skipped without explanation. This is the argument for cursor based paging on feeds that change constantly.
Page through while records are being deleted
TypeStatePriorityHigh- Test data
- Delete enough records to remove the last page while the reader is on it
- Expected result
- The reader is moved to the nearest valid page with a clear state, not left on an empty page with no rows and no explanation.
Request a page beyond the last
TypeBoundaryPriorityMedium- Test data
- page=999 on a three page set
- Expected result
- Empty state or a redirect to the last page. Never an error and never a blank screen.
Request invalid page values
TypeNegativePriorityHigh- Test data
- page=0, page=-1, page=abc, page=1.5, page as an array
- Expected result
- Normalised to the first page or refused with a clear error. No stack trace, no unbounded query.
Change the page size
TypeFunctionalPriorityMedium- Test data
- Each offered option, for example 10, 25, 50
- Expected result
- The row count matches the choice, the total page count recalculates, and the reader stays on an equivalent position rather than being thrown to page one unpredictably.
Enforce a maximum page size
TypeSecurityPriorityHigh- Test data
- pageSize=10000 and pageSize=999999 sent directly to the endpoint
- Expected result
- Capped at the documented maximum. An unbounded page size is a denial of service and a bulk extraction route in one parameter.
Measure the cost of a deep page
TypePerformancePriorityHigh- Test data
- Offset of ten thousand and one hundred thousand rows on production sized data
- Expected result
- Within the agreed response target. Offset paging degrades linearly, so a deep page is where a list view times out first.
Verify the total count is accurate
TypeFunctionalPriorityHigh- Test data
- Compare the stated total against the number of records actually reachable
- Expected result
- They agree. If the total is an estimate for performance reasons, the interface says so rather than stating a precise wrong number.
Verify the count and rows respect permissions
TypeSecurityPriorityHigh- Test data
- A list containing records the current user cannot access
- Expected result
- Restricted records are excluded from both the rows and the total. A count computed before permission filtering discloses how much exists.
Combine pagination with filters
TypeFunctionalPriorityHigh- Test data
- Apply a filter while on page three
- Expected result
- The reader returns to page one of the filtered set, the total reflects the filter, and the filter survives further paging.
Combine pagination with sorting
TypeFunctionalPriorityHigh- Test data
- Change the sort while on page two
- Expected result
- Sorting applies to the whole set rather than to the current page only, and the reader returns to page one.
Share and reload a paginated URL
TypeFunctionalPriorityHigh- Test data
- Copy the URL on page three with filters and sort applied
- Expected result
- Reopening reproduces the same page, filters and sort. Pagination state that lives only in memory cannot be shared or bookmarked.
Use the browser back button after paging
TypeStatePriorityMedium- Test data
- Advance three pages, then press back twice
- Expected result
- Returns through the page history rather than leaving the list entirely.
Return from a detail view to the list
TypeStatePriorityHigh- Test data
- Open a record from page four, then go back
- Expected result
- The list restores page four with its filters and scroll position. Losing the reader place is the most common complaint about paginated tables.
Verify the empty and single page states
TypeBoundaryPriorityMedium- Test data
- Zero records, then a set smaller than one page
- Expected result
- A clear empty message with a way forward, and pagination controls hidden or disabled rather than showing page one of one with dead buttons.
Verify infinite scroll behaviour if used
TypeFunctionalPriorityHigh- Test data
- Scroll through several loads, then reload the page
- Expected result
- No duplicate rows at load boundaries, a visible loading state, an end of list indicator, and either a restored position on return or an honest reset.
Verify scroll and focus position on page change
TypeAccessibilityPriorityHigh- Test data
- Move to the next page with a keyboard
- Expected result
- Focus moves to the start of the new results and the change is announced, rather than leaving focus on a control at the bottom of the page with no feedback.
Operate pagination controls by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver
- Expected result
- Controls are real buttons or links with accessible names, the current page is exposed as current, and disabled controls announce as disabled rather than being unreachable.
Verify exports and bulk actions against pagination
TypeFunctionalPriorityHigh- Test data
- Select all on page two, then export
- Expected result
- The interface makes clear whether the action applies to the page, the selection or the whole filtered set. Ambiguity here causes accidental bulk operations.
Verify behaviour when the data source is slow or unavailable
TypeNegativePriorityHigh- Test data
- Delay the request, then fail it
- Expected result
- A loading state, then a clear error with a retry. The previous page stays readable rather than being replaced by an empty table.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Anything that hides records from the reader, exposes records they should not see, or lets a request return unbounded rows is High.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Page forward, then page back
Every list passes on load. The defects appear on the second page and on the way back.
Seed identical sort values
Create twenty records with the same created date. Without a unique secondary key, rows repeat on one page and disappear from another.
Send a huge page size
Request ten thousand rows directly. An uncapped page size is both a denial of service and a bulk extraction route.
Go deep on real data
Offset paging degrades linearly, so page 400 of production data is where the list view times out first.
Open a record and come back
Losing the reader position on return is the most common complaint about paginated tables, and it is rarely in the test plan.
Four pagination defects that reach users
Unstable ordering produces the strangest bug reports you will receive. If the sort column is not unique, the database is free to return tied rows in a different order on every query, so a record shown on page one can appear again on page two while another is never shown at all. Users report missing data, and a single page test looks perfect. The fix is a unique tiebreaker on every sorted query.
A changing data set is the related problem. With offset paging, a record inserted at the top while the reader moves from page one to page two pushes one row down into the space they have already passed, so they never see it. On feeds that change constantly, cursor based paging is the correct answer rather than a nicety.
Page size is the security case. It looks like a preference and behaves like a parameter: uncapped, it lets anyone request the entire table in one request, which is both a performance risk and the easiest bulk extraction route in most applications. Cap it server side and reject anything above the cap rather than silently clamping.
Counts computed before permission filtering leak volume. The rows are filtered correctly but the total is not, so a user learns exactly how many records exist that they cannot see. Assert both the rows and the total against what that user is entitled to.
Suggest an improvementLists slowing down at scale?
QAble tests list and search performance against production sized data, including deep paging, unstable ordering and permission filtered totals.
Web application testingMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- RFC 9110: HTTP Semantics authoritative definition of methods, status codes and conditional requests.
- WCAG 2.2 the success criteria behind the accessibility cases.
- ISTQB Glossary standard definitions for the testing terms used here.
Want your data tables tested at real volume?
QAble builds functional and performance coverage with ISTQB-certified engineers. Start with a free QA audit of your product.