How to Write Test Cases for Pagination (With Examples)

How to Write Test Cases for Pagination (With Examples) is a practical guide that walks you through the anatomy of a pagination test case, shows you how to derive positive, negative, boundary, and edge

How to Write Test Cases for Pagination (With Examples) is a practical guide that walks you through the anatomy of a pagination test case, shows you how to derive positive, negative, boundary, and edge‑case scenarios, and ties those cases to requirements and autonomous exploration. The goal is to give you a reusable test matrix you can execute manually or automate, plus a short checklist you can bookmark for future pagination features.

Understanding Pagination Mechanics

Pagination splits a large result set into smaller, consumable chunks. Whether the data comes from a relational database, a NoSQL store, or a REST API, the core concepts are the same:

• Page size – number of items returned per request (often called limit, pageSize, or size).
• Cursor or offset – the starting point for the next chunk (offset, page, startIndex, or a token).
• Total count – optional field that tells the client how many items exist overall (total, totalElements, recordsTotal).
• Navigation controls – UI elements such as “Previous”, “Next”, page numbers, or infinite‑scroll triggers.

When a client requests page N, the service typically computes skip = (N‑1) * pageSize and returns items skip … skip+pageSize‑1. Edge conditions arise when:

• skip exceeds the total count → empty page.
• pageSize is zero, negative, or larger than the total count.
• The cursor token is malformed, expired, or tampered with.
• The underlying data changes between pages (inserts/deletes).

Understanding these mechanics lets you map each variable to a test condition and predict the exact system behavior.

Test Case Anatomy for Pagination

A well‑structured test case contains five essential parts:

Keep each step atomic and avoid bundling multiple assertions into a single step; this makes failure diagnosis faster. When writing automated scripts, map each step to a function or keyword (e.g., Playwright’s await page.goto(url)).

How to Write Test Cases for Pagination (With Examples): Positive and Boundary Cases

Positive cases verify that the system behaves correctly when inputs are within the declared contract. Boundary cases push those inputs to the limits of the contract (minimum, maximum, just‑inside, just‑outside). Below is a table of 22 representative cases. Feel free to copy the IDs into your test management tool and adjust the preconditions to match your domain.

Test Matrix (Positive & Boundary)

Each case isolates a single variable (page number, page size, cursor, sort, filter) while holding others constant. This makes it easy to trace a failure back to a specific requirement, such as “page size must be a positive integer ≤ maxPageSize”.

How to Write Test Cases for Pagination (With Examples): Negative and Error Cases

Negative cases probe how the system reacts when inputs violate the contract or when unexpected conditions arise. They are crucial for guarding against crashes, information leakage, or poor UX.

These cases ensure that validation, error handling, security, and resilience mechanisms are in place. When automating, assert on HTTP status codes, response headers, and that error messages do not contain stack traces or internal identifiers.

How to Write Test Cases for Pagination (With Examples): Edge Cases and Production‑Only Scenarios

Some defects only manifest under load, with real‑world data distributions, or when external systems behave unexpectedly. Capture them in your test plan even if they are hard to reproduce in a clean test environment.

These edge cases often surface only after the system has been in production for weeks or months, especially when data volume grows or when third‑party networks fluctuate. Documenting them helps you prioritize load‑testing, chaos‑engineering, and accessibility validation.

Prioritization, Traceability, and Data Setup

Not all test cases carry the same risk. Use a simple risk‑based matrix that combines impact (how severe a failure would be) and likelihood (how often the condition occurs in production).

Traceability – Map each test case to a requirement ID from your specification (e.g., `REQ-PAG-001: “The API shall return exactly pageSize items unless fewer remain.”). Keep a traceability matrix in your test management tool or a simple spreadsheet:

Data Setup – Automate the creation of the baseline dataset using scripts or Docker containers. For a relational database you might use:

-- create_base_data.sql
TRUNCATE TABLE items;
INSERT INTO items (id, name, status, type, created_at)
SELECT
  generate_series(1,1000000) AS id,
  'Item-' || generate_series(1,1000000) AS name,
  CASE WHEN (random() * 100) < 20 THEN 'inactive' ELSE 'active' END AS status,
  CASE WHEN (random() * 100) < 10 THEN 'premium' ELSE 'standard' END AS type,
  now() - (random() * interval '365 days') AS created_at
FROM generate_series(1,1000000);

For NoSQL or document stores, use a bulk import tool (e.g., mongoimport with a JSON array). After each test run that mutates state (delete, update), either roll back a transaction or reseed the database from a known snapshot. Keep the seed script under version control so every environment (dev, CI, staging) starts identical.

Manual vs Automated Execution Strategies

Manual Execution

• When to use – Exploratory testing, usability checks, accessibility validation, and ad‑hoc verification of edge cases that are hard to automate (e.g., screen‑reader navigation).
• How to execute – Follow the steps column verbatim, record observations in a test log, and capture screenshots or video for failures. Use a checklist (see later) to ensure you don’t skip preconditions like data reset.
• Tools – Browser dev tools for network inspection, Postman or Insomnia for API calls, accessibility auditors (axe, Lighthouse), and device labs for real‑device interaction.

Automated Execution

• When to use – Regression suites, CI pipelines, performance monitoring, and any case that can be expressed as a deterministic request/response interaction.
• API Layer – Use a language‑agnostic runner such as k6, Locust, or JMeter for load; for functional verification, use REST‑Assured (Java), pytest‑requests (Python), or SuperTest (Node.js). Example in Python:

import requests

def get_page(base_url, page, size):
    resp = requests.get(
        f"{base_url}/items",
        params={"page": page, "size": size},
        headers={"Accept": "application/json"},
        timeout=5,
    )
    resp.raise_for_status()
    return resp.json()

# Positive case PG-04
data = get_page("https://api.example.com", page=1, size=10)
assert data["total"] == 11
assert len(data["items"]) == 10
assert data["links"]["next"] is not None
assert data["links"]["prev"] is None

• UI Layer – For web applications, Playwright or Cypress can assert pagination controls, network responses, and DOM updates. Example Playwright snippet:

from playwright.sync_api import expect, sync_playwright

def test_next_button_disabled_on_last_page():
    with sync_playwright() as p:
        page = p.chromium.launch(headless=False).new_page()
        page.goto("https://app.example.com/items")
        # set page size to 10 via UI
        page.select_option("select#page-size", "10")
        # navigate to last page (calculate from total count)
        total = int(page.inner_text("span#total-count"))
        page_size = 10
        last_page = (total + page_size - 1) // page_size
        page.goto(f"?page={last_page}&size={page_size}")
        expect(page.locator("button#next")).to_be_disabled()

• Mobile Layer – For Android apps, Appium with Java or Kotlin can verify scroll‑based pagination. Example:

@Test
public void testInfiniteScrollLoadsMoreItems() {
    AndroidDriver<MobileElement> driver = getDriver();
    // Wait for initial list
    WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    wait.until(ExpectedConditions.numberOfElementsToBeMoreThan(
            By.id("item_row"), 0));
    int initialCount = driver.findElements(By.id("item_row")).size();

    // Scroll to bottom
    MobileElement list = driver.findElement(By.id("recycler_view"));
    ((JavascriptExecutor) driver).executeScript(
            "mobile: swipe", ImmutableMap.of(
                    "element", list.getId(),
                    "direction", "down",
                    "percent", 0.9));

    // Wait for new items
    wait.until(ExpectedConditions.numberOfElementsToBeMoreThan(
            By.id("item_row"), initialCount));
    assertTrue(driver.findElements(By.id("item_row")).size() > initialCount);
}

• Assertions – Besides status codes, validate:
• total matches the count of items in the database (or a derived count).
• No duplicate IDs appear across consecutive pages.
• Sorting order is monotonic according to the requested sort key.
• Links (next, prev) are present exactly when appropriate.
• Response time stays within SLA (use a timer assertion).

• CI Integration – Add the test suite to your pipeline with a stage that runs on every pull request. Use containerized test agents (e.g., docker run --rm -v $(pwd):/tests susatest-agent run --suite pagination) to guarantee environment parity.

Leveraging Autonomous Exploration (SUSA) for Pagination Coverage

SUSA explores an application without pre‑written scripts, generating real user interactions and capturing any anomalies. When you point SUSA at a paginated list, it will:

1. Discover navigation controls – It taps “Next”, “Previous”, page numbers, and infinite‑scroll triggers, learning which actions produce new content.
2. Vary personas – The curious persona may keep tapping “Next” until it hits the end; the impatient persona may jump to a high page number via URL manipulation; the accessibility persona will use screen‑reader gestures to verify announcements.
3. Detect regressions – If a recent change disables the “Next” button on the last page, SUSA will record a failure because the curious‑end state is missing.
4. Generate regression scripts – After a run, SUSA outputs Appium (Android) and Playwright (Web) scripts that reproduce the exact taps, scrolls, and inputs it performed. You can add these to your CI suite as a safety net.

How to invoke SUSA for pagination testing

# Install the agent (once)
pip install susatest-agent

# Point at a web URL; SUSA will crawl and paginate
susatest-agent run \
    --url https://shop.example.com/products \
    --personas curious impatient accessibility \
    --output-dir ./susausage-report \
    --generate-scripts

The --personas flag tells SUSA