Browse the Knowledge Hub32 resources
Test cases
Search test cases, weighted to relevance and leaks
Twenty eight cases covering exact and partial matching, typos, diacritics, filters, sort and pagination stability, injection, index lag, performance at production volume and accessibility. Searching for a word that exists is the one case that always passes.
All 28 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
28 worked examples
Return the expected record for an exact term match
TypeFunctionalPriorityHigh- Test data
- A term known to exist in one record
- Expected result
- The record appears, ranked first, with the matched term visible in the result.
Match on a partial word
TypeFunctionalPriorityHigh- Test data
- "inv" against "invoice"
- Expected result
- Prefix matches returned if the requirement says so. If the product only matches whole words, that is the documented behaviour and this case asserts it rather than assuming.
Search ignoring case
TypeFunctionalPriorityHigh- Test data
- INVOICE, invoice, Invoice
- Expected result
- Identical result sets and identical ordering for all three.
Search with multiple words
TypeFunctionalPriorityHigh- Test data
- "unpaid invoice march"
- Expected result
- Records matching all terms rank above records matching some. Word order does not change which records are found.
Match plurals and word stems
TypeFunctionalPriorityMedium- Test data
- invoice against invoices, run against running
- Expected result
- Stemming behaves as specified. This is where user expectation and implementation most often diverge.
Tolerate a single character typo
TypeFunctionalPriorityMedium- Test data
- "invocie"
- Expected result
- Fuzzy matching returns the intended record, or the interface offers a did you mean suggestion. Silence is a poor answer for a one letter error.
Search terms containing accents and diacritics
TypeBoundaryPriorityMedium- Test data
- cafe against café, Muller against Müller
- Expected result
- Matches in both directions, so users are not required to type diacritics.
Search in non Latin scripts
TypeCompatibilityPriorityMedium- Test data
- Terms in Devanagari, Arabic, Chinese and Japanese as supported
- Expected result
- Correct tokenisation and matching. Character based languages need language aware analysis rather than whitespace splitting.
Submit an empty search
TypeNegativePriorityMedium- Test data
- Blank field, then whitespace only
- Expected result
- Either the full list or a prompt, never an error and never a blank screen with no explanation.
Search a term with no matches
TypeFunctionalPriorityHigh- Test data
- A string certain not to exist
- Expected result
- A clear empty state naming the query, plus a way forward such as clearing filters or a suggestion. Not a zero row table.
Search below the minimum term length
TypeBoundaryPriorityMedium- Test data
- One character where the minimum is two or three
- Expected result
- The rule is stated in the interface rather than the search silently doing nothing.
Search with a very long query
TypeBoundaryPriorityMedium- Test data
- 500 and 5000 characters
- Expected result
- Handled or truncated deliberately with a message. No timeout, no 500, no unbounded query to the backend.
Search with special characters and operators
TypeBoundaryPriorityMedium- Test data
- %, _, *, ", -, +, AND, OR, NOT, and unbalanced quotes
- Expected result
- Either treated as literals or as documented operators. Unbalanced quotes must not error, and wildcards must not expand into a full table scan.
Attempt injection through the search field
TypeSecurityPriorityHigh- Test data
- ' OR 1=1 --, NoSQL operator objects, template expressions
- Expected result
- Treated as text. No query error, no altered result set, nothing in logs suggesting execution.
Attempt script injection reflected in the results heading
TypeSecurityPriorityHigh- Test data
- <script>alert(1)</script> as the query
- Expected result
- The "results for" text renders the payload as visible characters. Reflected cross site scripting through a search echo is a classic and still common finding.
Confirm results exclude records the user cannot access
TypeSecurityPriorityHigh- Test data
- Term matching a record owned by another user, tenant or restricted project
- Expected result
- Not returned, and not hinted at through a result count. Filter at the query, never in the interface.
Confirm deleted, archived and unpublished records are excluded
TypeSecurityPriorityHigh- Test data
- Soft deleted and draft records containing the term
- Expected result
- Absent from results for users without rights to them. Stale index entries after deletion are a frequent cause of leaks.
Combine a search term with filters
TypeFunctionalPriorityHigh- Test data
- Term plus status and date range filters
- Expected result
- Filters and term intersect. Result count matches the number of rows rendered.
Verify filter counts match reality
TypeFunctionalPriorityMedium- Test data
- Facet showing a count per option
- Expected result
- Selecting a facet returns exactly the stated number of records. Counts computed before permission filtering are wrong and leak volume.
Page through results and check stability
TypeStatePriorityHigh- Test data
- Navigate to page three, then back to page one
- Expected result
- No record appears twice or disappears. Unstable sort keys cause records to shuffle between pages, which readers experience as missing data.
Request a page beyond the last
TypeBoundaryPriorityMedium- Test data
- Page 999 of a three page result set
- Expected result
- Empty state or redirect to the last page. Never an error.
Share and reload a search URL
TypeFunctionalPriorityMedium- Test data
- Copy the URL with term, filters and sort applied
- Expected result
- Reopening reproduces the same query in the same state, and the browser back button returns to the previous result set rather than to a blank search.
Change sort order and verify it holds
TypeFunctionalPriorityMedium- Test data
- Sort by date then by relevance, with ties present
- Expected result
- Order is correct and deterministic. Tied records use a stable secondary key so repeated loads match.
Type quickly and check request behaviour
TypePerformancePriorityMedium- Test data
- Type twelve characters rapidly with search as you type enabled
- Expected result
- Requests are debounced, superseded responses are discarded, and the results shown correspond to the final query rather than to whichever response arrived last.
Search immediately after creating a record
TypeStatePriorityHigh- Test data
- Create a record, search for it within a second
- Expected result
- Found, or the delay is disclosed. Index lag that nobody documents produces support tickets claiming data loss.
Measure response time on a production sized dataset
TypePerformancePriorityHigh- Test data
- Full production volume, common and rare terms, worst case filters
- Expected result
- Within the agreed target at the ninety fifth percentile. Testing search on a thousand seeded rows measures nothing.
Behaviour when the search service is unavailable
TypeNegativePriorityHigh- Test data
- Search backend stubbed to error or time out
- Expected result
- A clear message and a usable page. The application must not hang, and must not fall back to an unfiltered list that ignores permissions.
Operate search and suggestions by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver
- Expected result
- Suggestions reachable with arrow keys and selectable with Enter, the result count announced when it changes, and focus managed so it does not jump back to the top of the page.
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. Any case where search returns records the user is not entitled to see is High, because search is the most common accidental data exposure route in a product.
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.
Test what search returns that it should not
Search is the most common accidental data exposure route in a product, and the least tested for it.
Search as the wrong user
Index a record in another tenant or project, then search for it. Filtering in the interface rather than the query is a routine finding.
Page forwards and back
Unstable sort keys shuffle records between pages, so users see duplicates and believe records vanished.
Use real data volume
Latency and relevance on a thousand seeded rows tell you nothing about behaviour on a million.
Break the search service
When the index is down, the dangerous fallback is an unfiltered list that ignores permissions.
Four search defects that reach production
Permission filtering applied after retrieval is the most serious. The query returns everything matching the term, and the interface hides what the user should not see. It works until the result count, a facet total or an export reveals the volume, or until a small change bypasses the display filter entirely. Test by indexing a record in another tenant and searching for it directly at the API.
Stale index entries are the second. A record is deleted or unpublished, the index is not updated, and search continues to return the title and snippet of content that no longer exists. Verify deletion propagation, and time how long it takes.
Pagination instability is the third and generates the strangest bug reports. If the sort key is not unique, the database is free to order tied records differently on each query, so a record on page one can appear again on page two while another is skipped. Users report missing data, and nothing looks wrong in a single page test.
The fourth is the search echo. Rendering "results for" plus the raw query without escaping is a reflected cross site scripting vector that has existed for twenty years and still ships regularly, because the field itself validates fine and only the echo is unsafe.
Suggest an improvementSearch behaving oddly at scale?
QAble tests search against production sized data, including relevance regression, permission filtering and index freshness.
Functional testing servicesMore 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 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 pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.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
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
- WCAG 2.2 the success criteria behind the accessibility cases.
- ISTQB Glossary standard definitions for the testing terms used here.
Want search tested at real volume?
QAble builds functional and performance coverage for search with ISTQB-certified engineers. Start with a free QA audit.