The product has many places: projects, screens, rules, tests, issues, visual checks, knowledge files. Finding something used to mean remembering which section it lived in and walking through tabs. Now a single search field stands above all of them: you start typing a word and the product immediately shows what it found, and a click opens the real place. You can search in Russian or in English: the words are recognized the same way.
Where the search field is
The field sits in the sidebar, right under the app’s name, so it is available from any screen. Wherever you are in the product, press ⌘K (on Windows and Linux — Ctrl+K) and the cursor lands in the field. The key works while the sidebar is visible: if it is collapsed, open it first.
You can end the search at any moment: Esc or the × in the field — and the page that was open before the search comes back. Simply clearing the text does the same.
How results are shown
Results appear at once, as you type, right in the content area — there is no “Search” button to press and no wait. The list is laid out by kind, so you do not have to hunt for the row you need by eye:
- Projects;
- Screens — the screens themselves, their types and comments on them;
- Rules and actions;
- Tests together with runs and failed steps;
- Scripts and failed script runs;
- Issues;
- Visual — snapshots, diff discussions, review todos, triage clusters, heal campaigns and agent sessions;
- The knowledge base and documentation.
Title matches come first: if the word is in a heading, that row appears higher. While the next query is being calculated, the previous list stays on screen and does not blink empty. If there are no matches, the product says so outright. Pressing Enter opens the first row of the list — faster than reaching for the mouse.
What you can find
Search covers everything you see in the interface: projects and their settings, screen types, screens and comments, rules, recorded actions, tests with their steps, scripts, issues, visual entities, as well as the text of knowledge files and documentation. You can search by words from a description, by a title, by error text — in short, by any place you wrote yourself.
It is most useful in two cases. First: you remember a problem but not which project it belongs to — the search takes you straight to it. Second: you need to recall the wording of a knowledge-base entry or a rule quickly, without opening the whole project.
Jumping to the real place
A list row leads not to a section in general but straight to what you were looking for:
- a project — to that project; a screen or a comment — to the screen itself;
- a rule — to the “Rules” tab, an action — to the “Actions” tab;
- a test — to the test itself; a run — to its build; a failed step — to that very test at that step;
- a script or a failed run — to the “Scripts” tab;
- an issue — to the project’s “Issues” section, with that issue’s card already open;
- a snapshot, a diff discussion or a triage cluster — to their build; a todo — to the todos board; a heal campaign — to the “Verify” tab.
Search also ends by itself along the way: the field empties, and what you opened stays on screen. There is no need to return to the found list — if you need it again, summon the search and repeat the query.
Knowledge and docs files open in place
Knowledge and documentation files are an exception to the navigation rule: they open right in the window above the results, read-only. Close — Esc, and you are back in the found list. That is handy for checking a wording without losing the search results.
Honest boundaries
- No secrets in search. Passwords, credentials and access keys are not entered into the search index, so you cannot find them with search even by accident.
- Only failed script runs get in. A successful run usually needs no investigation, while the error text is useful to search for — so that is what goes into search.
- Only failed steps get in from runs, not all of them.
- Search does not show edit history. It searches the current content: old versions of files and past revisions of descriptions are not found by it.
- A very large file does not get into search in full — up to 64 kilobytes of text. You can search the beginning of a large file, but a word from its middle will not be found.
- Search is for a person in the interface. It is unavailable through external access for agents: it is a field for you, not a machine address.
How search stays fresh
To find the right thing instantly, the product keeps a search index on disk — in the permanent data folder. The index is a pre-parsed list of all the content: search does not re-read everything on every query but opens a ready one. A restart does not require a rebuild — the index survives both a restart and a rebuild of the container together with its data.
Freshness is maintained by the product itself: an edit to a rule, a test or a knowledge file is picked up within a few seconds, without a restart and without your involvement. If the index is out of date or corrupt, it is rebuilt, and while the rebuild is going on search keeps answering from the previous copy — it never makes you wait. Where the index lives can be set with the TEST_APP_SEARCH_INDEX_FOLDER variable; by default it is /apps/test/search-index inside the permanent data.
Where to start searching is told in the Getting Started section. What else is visible on a project’s screen is in the Projects & Settings section. And what is available to machines through a separate key is in the External API Access section.