Pagination Testing Checklist (2026)

Pagination Testing Checklist (2026) provides a comprehensive, actionable list that teams can use to verify every aspect of paginated interfaces—from basic navigation to security, performance, and acce

Pagination Testing Checklist (2026) provides a comprehensive, actionable list that teams can use to verify every aspect of paginated interfaces—from basic navigation to security, performance, and accessibility—before a release. The checklist is organized into discrete test areas, each with clear pass criteria, real‑world examples, and guidance for both manual execution and automated coverage. By following this guide, engineers can catch regressions that only appear under specific data volumes, user interactions, or environmental conditions, and they can confidently sign off on pagination logic in web apps, mobile clients, or API‑driven feeds.

1. Introduction and Scope

Pagination is a ubiquitous pattern for presenting large collections of data in manageable chunks. Whether it is a news feed, product catalog, search results, or a settings list, the underlying mechanics share common requirements: correct state management, deterministic navigation, proper handling of empty or malformed data, and compliance with accessibility and performance standards.

A pagination testing checklist serves two purposes. First, it gives QA engineers a repeatable set of verification steps that can be executed manually during exploratory testing or integrated into CI pipelines. Second, it defines the observable behavior that automated scripts—whether written with Playwright, Appium, or generated by an autonomous agent—must assert.

The checklist below contains 30+ concrete items grouped into seven functional areas: happy path, error handling, edge/boundary cases, accessibility, security/privacy, performance, and release readiness. Each item includes a short description, pass/fail criteria, and a representative example. Where applicable, we note how an autonomous exploration platform such as SUSA can cover the item in a single pass without script maintenance.

> Note: The term “page” in this document refers to a logical view of paginated data, not necessarily a full HTML page rendered by a browser. The same principles apply to infinite‑scroll widgets, cursor‑based APIs, and mobile list views.

2. Happy Path Pagination Tests

The happy path validates that the core pagination flow works as expected under normal conditions. These tests form the baseline against which all other variations are measured.

2.1. Initial Load Shows Correct First Page

• Description: When the user opens the paginated view, the first set of items (usually items 1‑N) is displayed, and the UI indicates that this is page 1.
• Pass Criteria:
• The number of rendered items equals the configured page size (or fewer if total items < page size).
• The “previous” control is disabled or hidden.
• The page indicator shows “1 of X” (or “1” if total pages unknown).
• Example: A product listing with page size 20 shows exactly 20 items, the “Prev” button is greyed out, and the pagination bar reads “1 / 12”.
• Automation Hint: A Playwright test can locate the list container, count child elements, and assert the state of navigation buttons.

2.2. Navigation to Next Page Updates State Correctly

• Description: Clicking “Next” (or swiping forward) loads the subsequent chunk of data and updates UI indicators.
• Pass Criteria:
• The displayed items shift to the next range (e.g., items 21‑40).
• No duplicate items appear from the previous page.
• The “previous” control becomes enabled.
• The page indicator increments by one.
• Example: In a news feed, after tapping “Next”, the headline timestamps advance by exactly the page size, and the back button becomes tappable.
• Automation Hint: Use Appium to perform a tap on the “Next” button, then wait for a loading spinner to disappear before validating the new item indices.

2.3. Navigation to Previous Page Returns Exact Prior State

• Description: Using “Previous” after moving forward restores the exact UI state seen before the forward navigation.
• Pass Criteria:
• Item list matches the previously displayed set (same order, same identifiers).
• Page indicator decrements correctly.
• If already on the first page, the control remains disabled.
• Example: After viewing pages 2 → 3 → 4, tapping “Previous” three times returns the user to page 1 with the original item order unchanged.
• Automation Hint: Store a hash of the item IDs before navigation; after a series of forward/back actions, recompute and compare.

2.4. Direct Page Jump (If Supported) Lands on Correct Offset

• Description: Some paginated views expose a page selector or “Go to page” input. Jumping directly to a non‑adjacent page should display the correct slice.
• Pass Criteria:
• The displayed items correspond to the requested page number multiplied by page size (adjusted for zero‑based indexing).
• UI reflects the selected page.
• Example: Entering “7” in a page‑size‑10 list loads items 61‑70 and highlights “7” in the paginator.
• Automation Hint: Fill the input field, trigger the change event (e.g., press Enter), then verify the first item’s index.

2.5. Empty State Handled Gracefully

• Description: When the underlying data source returns zero items, the UI shows an appropriate empty‑state message rather than a blank list.
• Pass Criteria:
• A placeholder text or illustration is visible.
• Navigation controls are disabled/hidden.
• No JavaScript errors appear in the console.
• Example: A search results page with no matches displays “No results found. Try adjusting your filters.” and hides the paginator.
• Automation Hint: Assert the presence of an element with a known empty‑state identifier and the absence of list items.

2.6. Single‑Item Page Behaves Correctly

• Description: If the total number of items is less than the page size, the UI should still render correctly and disable unnecessary navigation.
• Pass Criteria:
• Only the actual items are shown.
• Both “Previous” and “Next” are disabled (or hidden).
• Page indicator shows “1 / 1”.
• Example: A user’s wishlist containing three items displays all three, with no scrollable pagination UI.
• Automation Hint: Check that the list length equals the total count and that navigation button attributes reflect a disabled state.

2.7. URL State Reflects Pagination (If Applicable)

• Description: For web applications that support deep linking, changing the page updates the URL query string or hash, and revisiting that URL restores the same page.
• Pass Criteria:
• Navigating to page k updates the URL (e.g., ?page=3).
• Reloading the page with that URL loads page k without additional user action.
• Example: A blog archive uses ?p=2; clicking “Next” changes the URL to ?p=3, and a direct visit to ?p=3 shows the third page.
• Automation Hint: After a navigation action, read window.location and assert the expected query parameter; then reload and validate the displayed page.

2.8. Touch/Gesture Navigation Works on Mobile

• Description: On touch‑enabled devices, swipe gestures should trigger page changes analogous to button clicks.
• Pass Criteria:
• Swipe left loads the next page; swipe right loads the previous page.
• Visual feedback (e.g., subtle animation) matches the button interaction.
• No accidental triggers occur when scrolling within an item.
• Example: In a photo gallery, swiping left on an image advances to the next image set, while swiping right returns to the previous set.
• Automation Hint: Use Appium’s swipe command with start and end coordinates, then verify the new page index.

2.9. Keyboard Navigation Accessible

• Description: Users who rely on keyboards can move between pages using arrow keys, Page Up/Page Down, or a dedicated shortcut.
• Pass Criteria:
• Focus is on a paginator control when the component mounts.
• Pressing ArrowRight triggers next page; ArrowLeft triggers previous.
• PageUp/PageDown shift by the configured page size (if supported).
• No focus traps occur.
• Example: A documentation site’s sidebar paginator reacts to ArrowDown to move forward through sections.
• Automation Hint: In Playwright, use page.keyboard.press('ArrowRight') and assert the resulting URL or DOM state.

2.10. Screen Reader Announces Page Changes

• Description: Assistive technology should announce the new page number or “next/previous” action when pagination changes.
• Pass Criteria:
• ARIA live region or aria-label updates are spoken.
• No extraneous announcements (e.g., announcing each item) cause verbosity.
• Example: A screen reader says “Page 3 of 10” after the user selects the third page from a dropdown.
• Automation Hint: While fully automating screen‑reader output is complex, you can verify that the relevant ARIA attributes change as expected.

3. Error Handling and Validation

Even the best‑designed pagination can encounter malformed responses, server errors, or client‑side bugs. This section checks that the UI degrades gracefully and provides useful feedback.

3.1. Non‑Numeric Page Input Is Rejected

• Description: If a user types letters or symbols into a page‑number field, the system should prevent navigation and show an inline error.
• Pass Criteria:
• The input does not trigger a page change.
• An error message appears near the field (e.g., “Please enter a valid number”).
• The control remains focused for correction.
• Example: Typing “abc” in a “Go to page” box displays a red border and the helper text “Invalid page number”.
• Automation Hint: Fill the field with invalid data, trigger the change event, then assert the presence of an error element and that the URL/page state is unchanged.

3.2. Out‑of‑Range Page Numbers Clamp or Show Error

• Description: Requesting a page beyond the total count should either clamp to the last valid page or display a clear error, never cause a crash.
• Pass Criteria:
• If clamping: the UI shows the last page and disables the “Next” control.
• If error: a message such as “Page 15 does not exist; total pages are 12” appears.
• No stack trace is shown to the user.
• Example: Entering “999” in a product catalog with 20 pages results in the UI staying on page 20 and a toast “You are already on the last page”.
• Automation Hint: Attempt to navigate to a page number > totalPages, then verify that the displayed page equals totalPages (clamp) or that an error element is visible.

3.3. Server Returns 5xx or 4xx on Page Request

• Description: Backend failures (e.g., database timeout) must be caught and presented as a user‑friendly error, not a blank screen.
• Pass Criteria:
• An error banner or modal appears with a concise message (e.g., “Unable to load more items. Please try again.”).
• The previously loaded items remain visible (if any).
• A retry option is provided.
• Example: While scrolling a feed, a 502 error triggers a modal with “Retry” and “Dismiss” buttons; the existing items stay on screen.
• Automation Hint: Mock the API to return a 500 status for a specific page request, then assert the error UI and that no navigation occurs.

3.4. Malformed JSON/Payload Causes Fallback

• Description: If the server returns data that does not match the expected schema (missing fields, wrong types), the client should handle it without throwing uncaught exceptions.
• Pass Criteria:
• The UI shows a placeholder or error for the affected items.
• The rest of the list (if any) remains usable.
• Console logs a warning but no error halts execution.
• Example: A news item missing a timestamp field renders with a dash “–” in the date column, while other items display correctly.
• Automation Hint: Inject a malformed response via a network interceptor, then verify that the list renders without crashing and that a fallback value is present.

3.5. Concurrent Page Requests Do Not Corrupt State

• Description: Rapid successive clicks (e.g., double‑tapping “Next”) should not cause multiple overlapping requests that lead to duplicated or missing items.
• Pass Criteria:
• Only the final requested page is displayed.
• Loading indicators prevent further clicks while a request is in flight.
• No duplicate entries appear in the list.
• Example: Spamming the “Next” button five times quickly results in a single page advance, with a spinner shown until the request resolves.
• Automation Hint: Use a loop to fire multiple click events in quick succession, then wait for network idle and verify the list length matches a single page size.

3.6. Stale Data Handled After Background Update

• Description: If the underlying data changes while the user is viewing a page (e.g., an item is deleted), the UI should either refresh the page or show a clear indication that the data may be stale.
• Pass Criteria:
• Option A: Automatic reload of the current page to reflect the new dataset.
• Option B: A banner stating “Some items have changed; pull to refresh”.
• No phantom items (IDs that no longer exist) remain visible.
• Example: In a chat list, deleting a conversation while viewing page 2 removes that conversation from the list without requiring a manual refresh.
• Automation Hint: Simulate a backend delete of an item currently rendered, then assert that the item is no longer in the DOM after a short wait.

3.7. Network Latency Simulated with Loading States

• Description: Under slow connections, pagination controls should show a loading indicator and disable further interaction until data arrives.
• Pass Criteria:
• A spinner or skeleton UI replaces the list during the request.
• Navigation controls are disabled (or ignore clicks) while loading.
• Upon completion, the list renders fully and controls re‑enable.
• Example: On a 3G‑simulated network, tapping “Next” shows a grayed‑out list with a spinner for 2 seconds before the new items appear.
• Automation Hint: Use network throttling (e.g., Chrome DevTools Protocol) to set a low download speed, then trigger a page change and verify the loading state appears.

3.8. Invalid Cursor/Token Values Are Rejected

• Description: For cursor‑based APIs, supplying an expired or malformed cursor should result in an error, not a silent fallback to the first page.
• Pass Criteria:
• The UI displays an error message such as “Unable to continue; please refresh”.
• No data is shown that could be misleading.
• Example: A social media feed returns a 400 error with {error: "invalid_cursor"} when the client sends a base64‑garbled cursor; the app shows a toast and retains the current page.
• Automation Hint: Intercept the request, modify the cursor parameter to an invalid value, then assert the error UI and that the list does not change.

3.9. Zero‑Length Page Size Handled

• Description: If the configuration permits a page size of zero (sometimes used for testing), the UI should not break and should show an empty state.
• Pass Criteria:
• No items are rendered.
• Navigation controls are disabled.
• An empty‑state message is visible.
• Example: A developer sets pageSize=0 in a feature flag; the list collapses to a placeholder “No items to display”.
• Automation Hint: Override the page size via API or local storage, then verify the empty‑state behavior.

4. Boundary and Edge Cases

Boundary testing focuses on the limits of data volume, index calculations, and unusual data patterns that can expose off‑by‑one bugs or integer overflows.

4.1. Exact Multiple of Page Size

• Description: When the total item count is an exact multiple of the page size, the last page should be fully filled and there should be no extra empty page.
• Pass Criteria:
• The final page contains exactly pageSize items.
• The “Next” control is disabled after reaching the last page.
• Page indicator shows totalPages / totalPages.
• Example: A catalog with 100 items and page size 25 shows four pages, each with 25 items, and the fourth page’s “Next” is greyed out.
• Automation Hint: Compute totalItems % pageSize === 0 and assert that the last page’s item count equals pageSize.

4.2. One Item Remainder (Partial Last Page)

• Description: When the total count leaves a remainder of one item, the last page should display that single item and not duplicate the previous page’s content.
• Pass Criteria:
• Last page contains exactly one item.
• No blank placeholders are shown to fill the page size.
• “Next” is disabled, “Previous” works.
• Example: 51 items with page size 10 yields five full pages and a sixth page with one item.
• Automation Hint: After navigating to the last page, count list items and verify the count equals totalItems % pageSize (or pageSize if remainder zero).

4.3. Very Large Total Count (Beyond 32‑bit)

• Description: Some services return totals that exceed 2^31‑1. The client must handle large numbers without overflow or loss of precision.
• Pass Criteria:
• Page numbers and offsets are stored in a type that supports the range (e.g., JavaScript Number safely up to 2^53‑1, or BigInt if needed).
• UI does not show NaN or Infinity.
• Navigation works for the highest accessible page.
• Example: A log‑viewing service reports 4 000 000 000 entries; the UI allows jumping to page 100 000 (pageSize = 40 000) and shows the correct slice.
• Automation Hint: Use a test data generator to produce a total > 2^31, then verify that page calculations produce integer results and that the UI does not display “NaN”.

4.4. Negative or Zero Page Number

• Description: Inputting a page number ≤ 0 should be treated as invalid and either clamp to 1 or show an error.
• Pass Criteria:
• The UI does not navigate to a negative page.
• Either the first page is shown (clamp) or an error message appears.
• Example: Typing “‑3” in a page jump box results in the UI staying on page 1 and an inline hint “Page number must be ≥ 1”.
• Automation Hint: Set the input to a negative value, trigger change, then assert that the displayed page is 1 and an error element is present.

4.5. Non‑Integer Page Size (If Allowed)

• Description: Some implementations accept fractional page sizes for virtualized scrolling (e.g., item height‑based). The system must round appropriately and not produce visual gaps.
• Pass Criteria:
• The effective number of items per viewport is an integer.
• No half‑rendered items appear.
• Scrolling remains smooth.
• Example: A virtual list with itemHeight=48px and viewport height = 300px computes a page size of 6 items (floor(300/48)).
• Automation Hint: Measure the rendered item count within the viewport and confirm it matches the floor of the division.

4.6. Duplicate IDs Across Pages

• Description: If the backend mistakenly returns the same identifier on two different pages, the UI should detect the duplication and either deduplicate or show an error.
• Pass Criteria:
• No two list items share the same primary key.
• If duplication is detected, a warning is logged and the duplicate is hidden or replaced with a placeholder.
• Example: A buggy API returns item ID 42 on both page 2 and page 3; the client filters out the second occurrence and shows a “Duplicate entry removed” toast.
• Automation Hint: After loading two consecutive pages, collect all item IDs and assert that the set size equals the total number of rendered items.

4.7. Out‑of‑Order IDs (Non‑Monotonic Pagination)

• Description: Some APIs return items sorted by relevance or timestamp, which may not be strictly monotonic when paging. The UI must not assume that the next page’s first ID is greater than the previous page’s last ID.
• Pass Criteria:
• The list order matches the order returned by the API for each page.
• No re‑sorting is performed unless explicitly required by product spec.
• Example: A search API sorts by score; page 1 ends with score 0.87, page 2 begins with score 0.91 (higher) – this is fine. The UI does not attempt to reorder based on ID.
• Automation Hint: Retrieve the raw API responses for two pages and compare the order of items in the DOM to the order in the responses.

4.8. Mixed Data Types in Same List

• Description: A paginated view may display heterogeneous items (e.g., ads mixed with organic results). The pagination logic must treat each entry as a single item regardless of type.
• Pass Criteria:
• Item count reflects total entries, not just a subtype.
• Navigation controls behave based on the total count, not the count of a particular type.
• Rendering of each type respects its own template without breaking the list flow.
• Example: A news feed inserts a sponsored card every 5th item; page size = 10 yields two sponsored cards per page. The “Next” button works as expected.
• Automation Hint: Count all list items (regardless of class) and verify that the number matches pageSize or the remaining count.

4.9. Page Size Change Mid‑Session

• Description: Users may adjust the number of items per page via a dropdown; the system must recalculate offsets and preserve the visual position as closely as possible.
• Pass Criteria:
• Changing page size does not jump to a random page; the first visible item before the change remains visible (if possible).
• The new page number is computed as floor(currentOffset / newPageSize) + 1.
• No duplicate or missing items appear after the change.
• Example: Switching from 10 items/page to 20 items/page while viewing item 24 keeps item 24 in the viewport and shows items 15‑34 on the new page.
• Automation Hint: Record the offset of the first visible item before the change, change the page size, then verify that the same item is still within the viewport after stabilization.

4.10. Rapid Page Size Fluctuations (Stress)

• Description: Repeatedly changing the page size in quick succession should not cause UI thrashing or memory leaks.
• Pass Criteria:
• After a burst of changes, the UI settles on a consistent state.
• No unbounded growth in DOM nodes or JavaScript heap observed.
• Interaction remains responsive.
• Example: A tester cycles the page size selector between 5, 10, 20, 50 ten times within five seconds; the list updates smoothly and the final state matches the last selected size.
• Automation Hint: Use a loop to dispatch change events with short delays, then force a garbage collection (if possible) and measure DOM node count before/after.

5. Accessibility (WCAG) Checks

Accessibility ensures that pagination is usable by people with diverse abilities. This section maps pagination features to WCAG 2.2 success criteria and provides concrete test steps.

5.1. Keyboard Operability (WCAG 2.1.1)

• Description: All pagination controls must be reachable and operable via keyboard alone.
• Pass Criteria:
• Tab order includes “Previous”, “Next”, page jump input, and any dropdowns.
• Enter or Space activates buttons.
• Arrow keys modify page number inputs where appropriate.
• Example: A user tabs to the “Next” button, presses Enter, and the page advances.
• Automation Hint: Use Playwright’s page.keyboard.press('Tab') in a loop to traverse focusable elements, then assert that page.evaluate(() => document.activeElement) matches the expected control.

5.2. Sufficient Contrast (WCAG 1.4.3)

• Description: Text and icons in pagination must meet a contrast ratio of at least 4.5:1 against their background.
• Pass Criteria:
• Automated contrast tools (e.g., axe-core) report no violations on pagination elements.
• Manual verification with a contrast checker confirms compliance for normal and large text.
• Example: The “Previous” button’s grey text on a white background fails at 3.2:1; changing to a darker grey passes.
• Automation Hint: Run npx axe-cli . --selectors '.paginator' in CI and assert zero violations.

5.3. Labeling and ARIA Roles (WCAG 4.1.2)

• Description: Each pagination control must have an accessible name that conveys its purpose.
• Pass Criteria:
• Buttons have aria-label or visible text (e.g., “Previous page”).
• Page jump input has an associated or aria-label.
• The paginator container may use role="navigation" and aria-label="Pagination"
• Example: A screen reader announces “Previous page, button” when focus lands on the left arrow.
• Automation Hint: Query each control and assert that element.getAttribute('aria-label') || element.textContent.trim() is not empty.

5.4. Live Region for Page Changes (WCAG 4.1.3)

• Description: When the page updates, assistive technology should be notified of the change without requiring the user to refocus.
• Pass Criteria:
• The list container or a sibling element has aria-live="polite" (or "assertive" for critical updates).
• The live region announces the new page number or “Page X loaded”.
• Example: After selecting page 4 from a dropdown, a live region reads “Page 4 of 12”.
• Automation Hint: Check for the presence of aria-live on the container and verify that its content changes after a page navigation (using page.waitForFunction).

5.5. Focus Management After Page Change

• Description: Keyboard focus should be moved to a predictable location after a pagination action to avoid disorientation.
• Pass Criteria:
• After activating “Next”, focus lands on the first focusable item of the new page (or returns to the paginator if configured).
• No focus trap occurs within loading spinners.
• Example: Pressing “Next” moves focus to the title of the first article on the new page.
• Automation Hint: Record the active element before the action, trigger the navigation, then wait for stability and assert that the new active element is within the newly rendered list.

5.6. Skip Links for Pagination (WCAG 2.4.1)

• Description: On pages with many paginated sections, a skip link allows users to jump directly to the pagination controls.
• Pass Criteria:
• A visually hidden link appears early in the DOM with href pointing to the paginator’s ID.
• Activating the link moves focus to the paginator without scrolling through intermediate content.
• Example: A long blog index provides a “Jump to pagination” link at the top; activating it sends focus to the page selector at the bottom.
• Automation Hint: Trigger a click on the skip link and then assert that document.activeElement matches the paginator container.

5.7. Touch Target Size (WCAG 2.5.5)

• Description: Touch targets for pagination controls must be at least 44 × 44 dp to accommodate finger interaction.
• Pass Criteria:
• Measured dimensions of “Previous”, “Next”, and any page buttons meet the minimum.
• Adequate spacing prevents accidental activation of neighboring controls.
• Example: A mobile app’s pagination arrows are 48 dp wide and tall with 8 dp margin, satisfying the guideline.
• Automation Hint: Use Appium’s getSize or getRect on the element and assert width ≥ 44 and height ≥ 44.

5.8. Reduced Motion Respect (WCAG 2.3.3)

• Description: If the system prefers reduced motion, pagination animations (e.g., slide, fade) should be disabled or substituted with a instant change.
• Pass Criteria:
• When prefers-reduced-motion: reduce is media‑queried, pagination transitions have transition: none or duration = 0 s.
• No flashing or moving content exceeds the three‑second threshold.
• Example: A user with reduced motion enabled sees the list swap instantly without a slide effect when pressing “Next”.
• Automation Hint: Emulate the media feature via page.emulateMediaFeatures([{ reducedMotion: 'reduce' }]) and then verify that CSS transition properties on the paginator are null or zero.

5.9. Error Messages Are Accessible (WCAG 3.3.1, 3.3.3)

• Description: Inline validation errors associated with pagination inputs must be programmatically linked to the input.
• Pass Criteria:
• Each invalid field has aria-describedby pointing to an error message element.
• Error messages are visible when the field is invalid and hidden when valid.
• Example: Typing “Please enter a number between 1 and 20” appears with aria-describedby="page-error" bound to the input.
• Automation Hint: After inducing an invalid input, confirm that the input’s aria-describedby attribute references a visible element with the error text.

5.10. Language of Content Announced Correctly

• Description: If the pagination controls contain language‑specific text (e.g., “Page”, “Of”), screen readers should announce them in the page’s declared language.
• Pass Criteria:
• The element has a valid lang attribute.
• No mixed-language strings cause mispron