Test Explorer

Introduction

What is the Test Explorer?

The Test Explorer is the screen at route /tests. It scans your project’s source files, finds every automated test (across many frameworks), and presents them as an organized, searchable list. For each test it shows its most recent result, its script status, its git owner and when it last changed, its recent run history and run count, any tags or modifiers, and a one-click Run button. Click any test to drop into a full-screen Detail View with tabs for Steps, Source code, run history (Runs), live Output, mapped manual test cases, and the framework Methods it uses.

Think of it as the table of contents for your test code. Just as a book’s table of contents lists every chapter with a page number without you having to flip through the whole book, the Test Explorer lists every test with its status and location without you having to open files in an editor or remember command-line incantations.

Note

In one sentence: the Test Explorer turns the test files scattered across your codebase into a single, filterable, runnable list with full result history.

Who this guide is for

• QA engineers and testers who need to find a specific test, run it, and read its result without touching a terminal.
• Developers who want to check whether the tests for a feature are passing, view the source of a failing test, or re-run a flaky one.
• Test leads and managers who want an at-a-glance pass-rate summary and the ability to export the test inventory to CSV or Excel for reporting.
• Anyone onboarding to a project who wants to understand what is tested, in which frameworks, and where the test files live.

Key terms (glossary)

These terms appear throughout the screen and this guide. Skim them once and the rest of the manual will read smoothly.

Term	What it means in the Test Explorer
Test	A single automated test case found in your source (for example one it(…), one Cucumber scenario, or one @Test method). It is the smallest runnable unit shown in a row.
Suite	A group of tests that live in the same file. Suites are the collapsible cards in the list; their name comes from the file or the top-level describe/feature block.
Framework	The tool the test is written for: Playwright, Jest, Vitest, Cypress, Cucumber, Mocha, Pytest, JUnit, TestNG, NUnit, xUnit, MSTest, RSpec, or Robot. Used for run commands, the framework filter and exports, and shown as a badge on the detail view’s Source tab.
Run	One execution of a test (or set of tests). Each run produces a result and is recorded in the test’s history.
Status	The result of the most recent run: passed (green check), failed (red X), skipped (grey minus), or no result yet shown as an empty circle.
Pass rate	The percentage of a test’s runs that passed, computed as passed runs / total runs. At the page level it is passed tests / tested tests (tests with at least one run).
Tag	A label attached to a test in the source (for example @smoke, @regression). Shown as cyan chips and usable as a filter.
Modifier	A marker on the test declaration that changes how it runs or what it means: skip, only, todo, fixme, or slow. Shown as small coloured badges.
Script status (lifecycle)	The authoring/maintenance state you assign to a test — Draft, Active, In Review, or Deprecated. Distinct from the run result (pass/fail); shown as a coloured pill you can change inline, and usable as a filter.

How it works

The Test Explorer does not run your tests in order to list them. When you open the page it scans your source files (you will briefly see Scanning test files…) and parses out every test declaration it can recognize. This is why a brand-new test appears in the list immediately after you save the file, even though it has never been executed.

Each discovered test is then matched against your run history. Testver remembers the results of every run you have performed (locally or on a cloud grid). When a test name matches a recorded result, the row is enriched with its last status, run count, pass/fail counts, and pass rate. A test with no matching history shows as No Run — it exists in your code but has never been executed through Testver.

Note

Two independent data sources feed every row: the source scan (what tests exist, their tags, modifiers, line numbers, framework) and the run history (what happened when they ran). A test can exist without history; history is never invented.

Getting Started

Opening the Test Explorer

1. Open Testver in your browser and make sure a project is loaded.
2. Click Test Explorer in the sidebar (route /tests). It opens on the Tests tab; the toolbar is titled Tests, next to the test-tube icon.
3. Wait briefly while you see Scanning test files… — Testver is reading your source.
4. The list appears. If no tests are found you will see an empty state with guidance (see Troubleshooting).

Tip

If you change a test file while the page is open, click the circular Refresh button on the far right of the toolbar to re-scan and pull in your edits.

The two views

The screen has exactly two modes. You are always in one or the other:

View	When you see it	What it is for
List View	The default. Shown whenever no specific test is selected.	Browsing, filtering, searching, sorting, multi-selecting, setting script status in bulk, saving a selection as a suite, and exporting the whole catalogue of suites and tests.
Detail View	Appears full-width the moment you click a test row.	Deep inspection of one test: its steps, source code, run history, live output, mapped manual test cases, and the framework methods it uses.

The Detail View replaces the list (it is not a side panel). A Back to Tests bar at the top returns you to the List View. The selection is reflected in the URL via ?file= and ?test= parameters, so a detail view is shareable and survives a page reload.

Screen layout

From top to bottom, the List View is built from these horizontal bands:

Region	Location	Contents
Header toolbar	Top	Tests title, status filter chips (All / Passed / Failed / No Run), framework dropdown (if more than one framework), the All Statuses script-status dropdown, and the right-side actions: Tags (when tests carry tags), Export, Refresh (plus Set status (N) and + Suite (N) when tests are selected).
Tag panel	Below toolbar (when opened)	The tag cloud for filtering by tag, or — when the cloud is closed but tags are active — a compact row of active tag chips.
Statistics strip	Below tags	Five stat pills: Total, Passed, Failed, No Run, and Pass Rate. Reflects the current filters.
Search + Sort + Selection bar	Above the list	Search box, the four sort buttons, and (when tests are selected) the N selected · Select All · Deselect All bar.
Suite list	Main scrollable area	The collapsible suite cards and, when expanded, their test rows.

The two tabs

The Test Explorer has a tab bar at the top. Each tab has its own guide:

Tab	Guide	What it shows
Tests	Tests tab	Every test Testver discovered in your project. Open any one for its source, run history, and output. The Explorer opens here.
Suites	Suites tab	Your own groupings of tests, each runnable as a unit with its own run options, schedule, and notifications.

The active tab is kept in the URL (/tests?view=suites), so it survives a refresh and can be bookmarked.

Common Tasks (How Do I…?)

Goal	How
Find a specific test	Type part of its name, suite, or tag into the Search box. Matching suites auto-expand.
See only failing tests	Click the Failed status chip.
See tests that never ran	Click the No Run status chip.
Mark a test’s script status	Click its status pill (Draft / Active / In Review / Deprecated) and choose.
See only Active (or Draft, etc.) tests	Pick a status in the All Statuses dropdown.
Set the script status on many tests at once	Tick their checkboxes, then click Set status (N) in the top-right.
Run one test	Click the row (or hover it and click the Play icon) to open the Detail View, then press Run Test.
Run a whole file	Hover the suite card header and click its Play icon.
Run several specific tests together	Tick their checkboxes, click + Suite (N) to save them as a suite, then run the suite from the Suites tab.
Run everything matching a filter	Apply your filters, click Select All, then + Suite (N), and run that suite.
Filter by one framework	Use the framework dropdown (visible only with multiple frameworks).
Filter by tag	Click Tags, then click the tags you want.
Read a test’s code	Open the test and use the Source tab.
See a test’s run history	Open the test and use the Runs tab.
See only cloud runs of a test	In the Runs tab, click the cloud-grid chip(s) in the Filter row.
Export the inventory	Click Export and choose CSV or Excel.
Jump to the file in the editor	Click the file:line link in the detail header, or Go to Definition in the Source tab.
Find which mapped manual cases cover a script	Open the test and use the Mapped TCs tab.
See what helpers a test relies on	Open the test and use the Methods tab.

Tips & Best Practices

Tip

After editing a test file, hit Refresh so the scan picks up renamed, added, or removed tests.

Tip

Combine filters: a framework + the Failed chip + a tag gives you, for example, all failing Playwright smoke tests — and the stat strip then summarizes exactly that subset.

Tip

Use Select All after filtering, then + Suite (N), to turn an entire failing subset into a suite you can re-run in one go — and later re-run only its failures with Re-run failed.

Tip

Export to Excel rather than CSV when you want the ready-made Summary and Tags sheets for a status report.

Tip

The left-edge colour of a suite card (green/red) lets you spot unhealthy files while scrolling, before expanding anything.

Tip

For Playwright failures, the Open in Trace Viewer link in the Output tab is the fastest path to a step-by-step replay of what went wrong.

Troubleshooting & FAQ

Why is a test showing ‘No Run’ / why is its Runs tab empty?

No Run means Testver found the test in your source but has no recorded execution of it. The test exists; it has simply never been run through Testver, so there is no history to show. Likewise the Runs tab will read No execution history yet. Run this test to see results here. The fix is simply to run it once — from the Detail View’s Run Test (the row’s Play button opens it), by running its whole file from the suite card’s Play button, or as part of a suite on the Suites tab. (If you ran it in some way Testver did not capture, the result will not appear.)

I see ‘No runs match the selected filter’ in the Runs tab.

The test does have history, but the Local/cloud Filter chips you have toggled exclude all of it. Clear the filter selection (deselect the active chips) to show all runs again.

What’s the difference between the suite Play, the row Play, and + Suite?

Action	What it runs	How
Suite Play (card header)	Every test in that one file.	Builds a file-level command for the whole suite and launches it immediately.
Row Play (single test)	Just that one test.	Opens the test’s Detail View; the run is scoped to that single test via its own command (with a name/line filter). You start it from there.
+ Suite (toolbar, with tests selected)	Nothing immediately.	Opens Add to suite, where you create a new suite or add the checked tests to an existing one. The suite then runs from the Suites tab, each test with its own command.

No tests appear at all.

You will see No tests found with guidance to add test files. Testver recognizes patterns such as .spec.ts, .test.ts, .feature, test_*.py, and *Test.java among others. Ensure your project actually contains such files and click Refresh. If scanning errored, an Error loading tests state is shown with the error detail instead.

The framework dropdown is missing.

That is expected when the project uses a single framework — there is nothing to filter between, so the dropdown is hidden.

The Tags button isn’t there.

The Tags button only appears when at least one test in the project carries a tag. No tags in the source means no tag panel.

Why does the command pill say ‘Custom’ vs ‘Auto’?

Auto means Testver generated the run command for you from the framework and test name. Custom means you have configured a custom single-test command in settings, and that is what will run.

Run Test is greyed out on a mobile test.

Mobile/Appium tests require a target device. Until you select a local device (and, for cloud, an app) in the device picker, Run Test stays disabled. The button’s tooltip tells you exactly what is missing — connect a local device or enable a cloud grid in Connectors, then pick a device and app.

Related

• Runner — the execution engine.
• Results — full run artifacts.
• Script Mapping — link tests to cases.