We can see search systems in almost every second of software that comes out in production. And it is very convenient when testers have some kind of “useful cheat sheet” with points that need to be checked and the ones that can be skipped.

We’ll present this material in the form of a small checklist.

What Should Be Tested First?

• The search correctly finds results for all fields that are described in the technical requirements;
• The search does NOT find results for all fields that are NOT described in the technical specification;
• Correctness of relevance of the issue;
• Context of search results;
• Case insensitivity;
• Whether the system is functioning on inclusion or full search match;
• 2 and more words from one search field;
• 2 and more words from different search fields;
• Typing mistakes;
• Incorrect keyboard layout;
• Another system language;
• Non-alphanumeric characters;
• Using emojis;
• Blank value;
• Space characters in fields;
• Low limit;
• Search for the technological frontier.

After all these tests, we can get some results on correct performance of search, namely:

1. Specific fields where the search works, and the ones where it shouldn’t work by default.
2. Does the system work on enabled compliance?
3. Is the search system case-sensitive?
4. What is the maximum length of a searching box?
5. Is the request cut off, if this length is exceeded?
6. How does the search work within an empty response?

To Conclude

It is always worth remembering that the best way to test is from the most difficult things to the simplest ones. Why do we need the search, anyway? To be able to filter requests by specific fields. It means that first of all, we need to test the following:

• The search works on those fields that are stated in requirements specification;
• The search DOESN’T work on those fields that AREN’T stated in the requirements specification.

And only then we need to test registers, typos, special characters, and so on. We follow from simple to complex, because if we start checking all possible errors in one test, in the future it will be difficult to understand why the search does not work as it should.

Also, don’t forget about typical tests for any test field. There are the length tests:

1. Diverse register/languages.
2. Empty value/fields consisting of spaces only.
3. Lower bound – are there adequate but short data? Does the system find from these data?
4. The upper arbitrary border – if any.
5. Search for a technological frontier – trying to enter a large number of words, preferably with several spaces.

This material is some kind of effective solution for checking any text search bar. Meaning, it has a lower priority than tests of specific functionality. And it doesn’t matter what you have – search, filters, or something else. You should always start the testing process with the most important things!