Junior · Feature Interaction Testing

Search, Filter & Pagination Testing

Every e-commerce site, admin panel, and content site has search and filtering. But most testers skip the boundary conditions and state persistence bugs that live here. Learn the patterns that catch 90% of real-world defects.

Junior ISTQB CTFL 4.3 — K3 Apply ~13 min read + exercise

1 The Hook — Why This Matters

A major NZ retail site launched an inventory search with filtering. The tester verified that searching for "shirt" returned shirts, and filtering by colour worked. Launch green light. Within two hours, a customer reported that the search worked on Page 1, but when they clicked "Next Page," their filter was forgotten and they saw unfiltered results. They assumed the product didn't exist and left the site. Sale lost.

The bug was a single line: the developer forgot to preserve the filter parameter in the pagination URL. The tester never clicked Next after applying a filter. Cost to the business: lost sales and negative reviews. Cost to the tester's credibility: significant.

This page teaches the test patterns that catch these real-world defects. Search, filter, and pagination are interdependent systems. You must test them together.

2 The Rule — The One-Sentence Version

Test search, filter, and pagination independently first, then test them combined. Always verify URL state persistence and browser back button behaviour.

Most bugs don't happen in isolation. A search that works on Page 1 might fail on Page 3 with a large result set. A filter that works alone might break when combined with sorting and pagination. The hidden bugs live in the interactions, not the features.

3 The Analogy — Think Of It Like...

Analogy

Searching through a filing cabinet with dividers and bookmarks.

You can pull out the drawer (search), you can use dividers (filters), and you can flip through pages (pagination). But if you pull the drawer, use a divider, flip to page 3, then flip back to page 1, does the divider still apply? If you bookmark a specific page with a divider, and come back tomorrow, is the divider still there? These are state questions. Most search/filter/pagination bugs are state bugs: the system forgets what the user selected when they navigate elsewhere.

4 Watch Me Do It — Step by Step

Here is a systematic walkthrough testing a real e-commerce product search with filtering and pagination. The site is a Kiwi electronics store.

  1. Search: basic functionality Search for "laptop". Verify the result count updates. Check that results actually contain the search term. Verify exact match vs partial match: does searching "lap" find "laptop"?
  2. Search: special characters Test with quotes ("), apostrophes ('), asterisks (*), ampersands (&), and plus signs (+). A NZ product called Ben & Jerry's should be findable with ben, ben & jerry's, and "ben & jerry's".
  3. Search: case sensitivity Does LAPTOP, laptop, and LaPtOp all return the same results? They should.
  4. Search: empty and no results Search for a term that returns zero results (e.g., xyzabc123). Does the UI show "No results found" clearly? Does pagination disappear? Does the filter panel still work (so users can broaden their search)?
  5. Filter: single filter applied Apply one filter (e.g., Category = "Laptops"). Verify the result count changes and all results match the filter. Check the filter is visually indicated as active.
  6. Filter: multiple filters (AND logic) Apply two filters: Category = "Laptops" AND Price = "$1000-$2000". The result count should be equal to or less than the single filter. Verify all results meet both criteria.
  7. Filter: clearing filters Apply filters, then click "Clear all filters". Verify results return to unfiltered state. Check that filter UI elements reset (checkboxes, sliders, dropdowns).
  8. Pagination: page boundaries On a search with 47 results showing 10 per page: Page 1 shows items 1-10, Page 2 shows items 11-20, Page 3 shows items 21-30, Page 4 shows items 31-40, Page 5 shows items 41-47 (partial page). Verify each page shows the correct item count and range.
  9. Pagination: first/previous/next/last navigation Verify all buttons are disabled/enabled appropriately. On Page 1, "Previous" should be disabled. On the last page, "Next" should be disabled. Jump to Page 3 using page number input, then verify Previous and Next work correctly.
  10. Search + Filter + Pagination combined Search for "laptop", apply filter Category = "Gaming", verify results on Page 1. Click to Page 2. Verify the search term AND filter are still applied. Change the items-per-page to 25, verify pagination adjusts and page numbers change.
  11. URL state persistence Apply a search, filter, and navigate to Page 2. Copy the URL. Open a new tab and paste the URL. All state should be restored: the search term, filter, and pagination should be identical to what you left.
  12. Browser back button Search for "laptop", click to Page 2. Click browser Back. Verify you're back on Page 1 with the search term preserved. Click Forward. Verify you're back on Page 2. State should be preserved across navigation.
Search & Filter Test Case Template
Test Case: Search + Filter + Pagination Combined
Precondition: User on electronics store product page with 200+ products

Test Steps:
1. Enter "laptop" in search box
   Expected: Shows ~30 results containing "laptop"
2. Apply filter: Brand = "Dell"
   Expected: Shows ~8 results (Dell laptops only)
3. Click "Next Page"
   Expected: Shows next 10 results, search + filter preserved in URL
4. Click page number "3"
   Expected: Shows page 3 results, URL updated with page=3&search=laptop&brand=Dell
5. Copy URL and paste in new tab
   Expected: New tab shows identical results with same search + filter
6. Click browser Back button
   Expected: Returns to page 2 with search + filter intact
7. Clear filters
   Expected: Returns to showing all laptop results (no brand filter)

Pass Criteria:
- All steps produce expected results
- URL contains all query parameters
- Browser back/forward preserves state
- No results lost when changing pages
Pro tip: Most developers build search and pagination independently, then integrate them. The integration is where bugs hide. Always test combinations, not just individual features.
Search Special Characters Cheat Sheet
CharacterTest case exampleExpected behaviour
Apostrophe (')Search "Ben & Jerry's"Should find products with apostrophes
Ampersand (&)Search "fish & chips"Should find products with ampersands
Quote (")Search for exact phrase "wireless headphones"Should return exact matches, or handle gracefully
Asterisk (*)Search "head*" (wildcard)Depends on spec; verify consistency
Plus (+)Search "ultra+bright"Should find hyphenated or compound terms
Hyphen (-)Search "long-sleeve" or "Sony-brand"Should find hyphenated products
Macron (ū, ā, etc.)Search "Māori art"Important for NZ localization; test diacritics

5 When to Use It / When NOT to Use It

✅ Use this testing when...

  • The application has user-facing search functionality
  • Users can filter results (by category, date, status)
  • Results are paginated (showing 10-100 results per page)
  • The site has sorting (by price, date, relevance)
  • Results can be bookmarked or shared via URL
  • Users expect state to persist across navigation

❌ Don't use it when...

  • There is no search or filter functionality
  • Results are displayed all at once (no pagination)
  • Results are in a modal or temporary view (not shareable)
  • The UI is read-only display (no interactive filtering)
  • State persistence is explicitly not required

Before you test search/filter/pagination, ask:

  • Are search, filters, and pagination integrated into a single feature?
  • Can users bookmark or share a filtered search URL?
  • What happens when pagination and filters interact?

6 Common Mistakes — Don't Do This

🚫 Testing each feature in isolation

I used to think: If search works, filters work, and pagination works, the system works.
Actually: The bugs live in the interactions. A filter that works on Page 1 might break on Page 3 because the developer forgot to pass the filter parameter to the next page query. Testing search alone, then filters alone, then pagination alone misses 80% of real defects. Always test combinations.

🚫 Not testing state persistence

I used to think: As long as the current page shows correct results, the feature works.
Actually: Modern web expects state to persist. Users expect to copy a filtered search URL and send it to a friend. They expect the browser Back button to work. If your system doesn't preserve state in the URL or history, you've broken shareable links and browser navigation. Always test URL preservation and browser back/forward.

🚫 Testing only the happy path

I used to think: Testing a search that returns results is enough.
Actually: The edge cases are where bugs hide. Test with zero results, with 1 result, with 10,000 results. Test the last page (which usually has a partial result set). Test page boundaries where the item count doesn't evenly divide (47 items ÷ 10 per page = 4 full pages + 1 partial page with 7 items). Off-by-one errors in pagination math happen at these boundaries.

When search/filter/pagination testing fails

Often the problem is that filters aren't passed through pagination queries, or URLs don't include filter parameters. Also watch for sorting breaking when filters are applied, or pagination counts being incorrect after filtering. Always inspect the URL bar and Network tab to see what parameters are being sent.

7 Now You Try — A Book Store Search

🎯 Interactive Exercise

Scenario: You are testing an NZ book retailer. The search and filter system allows users to search for books, filter by category and price, and paginate through results (10 per page).

Your task: Identify at least five test cases that cover interactions between search, filter, and pagination. Include at least one state persistence test.

Suggested test cases for book store search:

Test caseStepsCritical check
Search aloneSearch "Maori history" on Page 1Results show only matching books
Filter + SearchSearch "history", apply filter Category="NZ Non-fiction"Results are filtered AND match search
Pagination after filterApply filter, click Page 2Filter parameter persists in URL; results still filtered
URL state persistenceSearch "fiction", filter "Under $20", go to Page 2, copy URL, open new tab, pasteNew tab shows identical results with same filters
Browser back buttonSearch "cookbook", apply price filter, click Page 3, click browser Back twiceReturns to Page 1 with search and filter intact
Clear filters + paginationApply filters, go to Page 2, click "Clear filters"Returns to Page 1 of unfiltered results

Key insight: The most common bug in these tests is that the developer preserved the search term in pagination but forgot to preserve the filter parameter. Always inspect the URL bar to see which parameters are being passed from page to page.

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to practice.

Q1. Why must you test search, filter, and pagination as an integrated system?

Because the bugs live in the interactions, not the features. A filter that works on Page 1 might fail on Page 3 if the developer forgot to pass the filter parameter to the pagination query. A search that works might break when sorted. Testing each feature in isolation will miss 80% of real defects.

Q2. What is the most important test for search/filter/pagination?

Testing state persistence: apply a search, filter, and navigate to a specific page, then copy the URL, paste it in a new tab, and verify the results are identical. This catches the bug where developers forget to include search/filter parameters in the pagination URL.

Q3. Name three edge cases you must test in pagination.

Three critical boundaries: (1) the last page with a partial result set (e.g., 47 items showing 10 per page, last page has 7 items), (2) zero results (does the UI handle "no results found" correctly?), and (3) very large result sets (does pagination slow down or break at 10,000+ results?). Also test off-by-one errors: Page 1 should show items 1-10, not 0-9.