Type "pizza" into a food delivery app. Results appear. Search works. Ship it.
That's roughly the level of search testing most teams do before release. Then users start reporting: "I searched for 'piza' and got zero results." "The search bar disappears when I rotate my phone." "I applied a filter for vegetarian and got chicken wings." "Search takes 8 seconds on my Galaxy A14."
Search is deceptively simple to use and surprisingly hard to test well. It touches input handling, backend query logic, result ranking, filtering, pagination, autocomplete, and UI behavior across screen sizes and network conditions. A single search box connects to more moving parts than most features in the app.
This guide covers what to test and where search actually breaks, organized by failure category rather than by an abstract checklist nobody reads twice.
Where search breaks: input handling
The search box is the front door. If it handles inputs poorly, nothing downstream matters.
Empty query. Tap the search icon or press Enter without typing anything. Some apps crash. Some return every item in the database. Some show a helpful "Type something to search" message. The right behavior depends on your app, but crashing or returning 50,000 results isn't it.
Special characters. Type %, ', ", <script>, --, or SELECT * FROM. These are both usability edge cases and security tests. A % sign shouldn't redirect to a 404. A single quote shouldn't break the SQL query underneath. A <script> tag in the search box should never execute. If your search passes the query directly to a database without sanitization, you have a SQL injection vulnerability, not just a search bug.
Very long queries. Paste a 500-character string into the search field. Does the app handle it? Does the field truncate? Does the API timeout? Does the keyboard lag while rendering the text? On mobile, long text in a search field can cause the UI to hang because the field is re-rendering on every character.
Leading and trailing spaces. Search for " pizza " (with spaces before and after). If the backend doesn't trim whitespace, it searches for a literal " pizza " which might return zero results even though "pizza" has 200 matches.
Case sensitivity. "Pizza", "pizza", and "PIZZA" should all return the same results. This sounds obvious, but it's a backend configuration that's easy to forget. Especially when the search index uses exact matching by default.
Copy-paste behavior. Copy a product name from somewhere else and paste it into the search field. On some mobile devices, paste inserts hidden Unicode characters (zero-width spaces, non-breaking spaces) that look invisible but break the search query. The user sees "pizza" but the search engine receives "pizza" with zero-width spaces between each letter.
Where search breaks: results quality
The search returns results. Are they the right ones?
Relevance ranking. Search for "iPhone case" on an e-commerce app. The first result should be an iPhone case, not a case study about iPhones or a phone case for a Samsung that mentions "iPhone" in the description. Relevance ranking is the hardest part of search to get right and the easiest to get wrong.
Typo tolerance. Search for "piza" instead of "pizza." A good search engine returns pizza results with a "Did you mean: pizza?" prompt. A bad one returns nothing. Users misspell words constantly, especially on mobile keyboards where the keys are small and autocorrect sometimes makes things worse.
No results handling. Search for something that genuinely doesn't exist in your catalog. The app should show a clear "No results found" message, ideally with suggestions ("Try a different spelling" or "Browse popular categories"). An empty screen with no explanation is a UX failure.
Partial matching. Search for "lap" on an electronics store. Should it return "laptop" results? Most users expect it to, especially if autocomplete suggests "laptop" as they type. But the search might be configured for exact matches only, returning nothing for "lap."
Newly added items. Add a new product to the catalog and immediately search for it. Does it appear? If the search index updates on a schedule (every hour, every day), newly added items won't be findable until the next index refresh. Users see the item on the category page but can't find it through search. Confusing.
Where search breaks: filters and sorting
Filters narrow results. Sorting reorders them. Both break in ways that are hard to notice.
Filter + search combination. Search for "pizza" and apply the "Vegetarian" filter. Every result should be vegetarian pizza. If a chicken pizza appears because it has "vegetarian options available" somewhere in its description, the filter logic is matching the wrong field.
Removing filters. Apply a filter, then remove it. Do the results reset to the unfiltered state? Or do they stay stuck on the filtered set? This is a common state management bug on mobile where removing a filter doesn't trigger a fresh query.
Sort stability. Sort results by "Price: Low to High." Scroll down. Go to page 2. Are the results actually in price order across pages? Or does each page sort independently (page 1 is sorted, page 2 starts over from a different set)? Pagination + sorting is a backend bug that's invisible unless you check results across multiple pages.
Filter counts. Some apps show the number of results per filter option ("Vegetarian (24)"). Apply the Vegetarian filter. Are there actually 24 results? If the count says 24 but only 18 appear, the count and the query are using different logic.
Where search breaks: performance
Search performance is about speed and stability under load.
Response time on slow networks. Switch your device to a throttled 3G connection. Search for something. How long until results appear? If the app shows a blank screen for 6 seconds with no loading indicator, the user thinks it's frozen. A loading spinner or skeleton UI should appear within 300ms.
Autocomplete latency. Start typing in the search field. How quickly do autocomplete suggestions appear? They should render as the user types, ideally within 200-300ms per keystroke. If autocomplete lags by a full second, the user has already finished typing and the suggestions flash uselessly.
Search under concurrent load. This is a backend concern. If 1,000 users search simultaneously during a flash sale, do response times hold? Or do they spike from 200ms to 5 seconds? Load test the search API endpoint separately from the rest of the app, because search queries often hit a separate search index (Elasticsearch, Algolia, Solr) that has its own capacity limits.
Large result sets. Search for a generic term like "shirt" on an e-commerce app with 50,000 products. Does the app handle the massive result set with pagination? Or does it try to load all 50,000 at once and crash?
Where search breaks: mobile-specific
These are the search bugs that only show up on phones.
Keyboard covers the results. On some devices, tapping the search field opens the keyboard, and the keyboard covers the area where results would appear. The user types a query, results load behind the keyboard, and they can't see them until they dismiss the keyboard. This is a layout issue where the search results container isn't adjusted for keyboard height.
Voice search. If your app supports voice input (most Android devices offer it via the keyboard microphone button), test that voice-transcribed text triggers a search correctly. Voice transcription sometimes adds punctuation or capitalization that the search backend doesn't expect.
Rotation during search. Type a query, see results, rotate the device to landscape. Do the results persist? Does the query text stay in the search field? On many apps, rotating triggers a layout rebuild that clears the search state. The user has to retype their query.
Search on different screen sizes. On an iPhone SE (4.7-inch screen), the search bar, keyboard, and results all compete for the same small viewport. On an iPad, the same search interface might look empty with too much whitespace. Responsive design matters for search more than most features because the search workflow involves an input field, a keyboard, and a results list, all visible simultaneously.
Back button behavior. The user searches for "pizza," taps a result, reads the product page, then taps the back button. Do they return to the search results with "pizza" still in the search field and the results still loaded? Or do they return to a blank search screen and have to retype? On Android, the back button behavior depends on how the search screen manages its back stack. Getting it wrong is one of the most common mobile search UX bugs.
Automating search tests
The repetitive search tests (empty query, special characters, case sensitivity, filter combinations) are good automation candidates. They run the same inputs every time and have clear pass/fail criteria.
For mobile search automation, the test needs to: tap the search field, type a query, wait for results, and validate what appears. That's a standard interaction flow that works with any E2E testing tool. The tricky part is validating result CONTENT (are the results relevant?) rather than just result PRESENCE (did something appear?). Most automation validates presence. Relevance validation requires either a known test dataset with expected results or a human reviewer.
The mobile specific tests (keyboard covering results, rotation state loss, back button behavior) are harder to automate because they depend on device-level interactions that vary across manufacturers. Exploratory testing sessions are better for these: a tester on a real device rotates, presses back, opens the keyboard, and watches what happens.
FAQ
What is the first thing to test in search functionality?
The empty query. Tap search without typing anything. If the app crashes, returns the entire database, or shows no feedback, you've found a bug before testing a single real query.
How do I test search relevance?
Use a known dataset. Search for "iPhone case" and verify that iPhone cases appear first, not unrelated products that mention "iPhone" in the description. Compare the top 5 results to what a human would expect for that query.
Should search be case-sensitive?
Almost never for user-facing search. "pizza", "Pizza", and "PIZZA" should return the same results. Case-insensitive search is a backend configuration (collation settings in SQL, case-insensitive analyzers in Elasticsearch).
How fast should search results load?
Under 1 second for the initial results on a good connection. Under 3 seconds on 3G. Autocomplete suggestions should appear within 200-300ms per keystroke. Anything slower feels broken to the user.
What mobile-specific search bugs should I look for?
Keyboard covering results, search state lost on device rotation, back button clearing the search query, voice search transcription errors, and layout issues on small screens (iPhone SE) versus large screens (iPad).
Can search testing be automated?
Input handling (empty queries, special characters, long strings) and filter validation automate well. Result relevance and mobile-specific UX behaviors (rotation, back button, keyboard layout) are better tested manually or through exploratory sessions.
