Glossary
Quick reference for the vocabulary used across Testver. If a screen uses a term and you’re not sure what it means, find it here — most entries link to the screen where the term actually appears.
Admin The administrator role, second only to the Super admin. Can manage users, read the Audit Log, and change org-level Settings — on top of everything a Tester can do.
AI Assistant The built-in chat that helps you write, fix, and analyse tests using a connected LLM. See AI Assistant.
AI Record A tool that captures a browser session — or taps on a phone — (clicks, typing, assertions, notes, custom steps) and turns it into a generated test script. See AI Record.
AI Test Gen Generates test cases from requirements or scripts. See AI Test Gen.
App Mode (Testing Mode) Whether this Testver instance is set up for Web or Mobile automation. Chosen during first-time setup and changeable in Settings → General. Controls which surfaces (Runner, Recorder, Schedules) are shown.
Agent Skill (Skill) A reusable, packaged capability the AI can invoke for a specialised task. See Agent Skills.
API key A credential that lets Testver use AI features. Cloud AI is authorized by connecting your Testver account on Testver → Connections; local providers (Ollama, LM Studio) need no key at all. Providers are listed in Settings → LLM.
Audit Log The record of who did what, when. Admins and the Super admin only. See Audit Log.
Automation Coverage
The share of your test cases that have a script mapped (and can thus run automatically): automated test cases / total active test cases. See Coverage.
Auto-Heal Repairs a locator that broke because the page changed, using the evidence the failed run left (a Playwright trace, the browser session, a recorded fallback), then re-runs the test to verify the fix. See Auto-Heal.
Browser (run target)
A named entry in Settings → General → Run Configuration — “Firefox” — plus what it means when a run starts: a command-line argument (--project=firefox, -Dbrowser=firefox) or an environment variable (BROWSER=firefox). Picked by name in Test Explorer, Suites and Cycles. See Settings.
Catalog The full set of tests Testver discovered by scanning your project (the Test Explorer view). The Dashboard’s health cards are derived from the catalog, not from run history.
CI run One trigger recorded by the CI/CD Pipelines screen, linking the CI build metadata (branch, commit, build number) to the test run it caused. Distinct from the test run itself, which appears in Results.
CI token
A long-lived machine token (tvci_…) that lets a CI job or the testver trigger CLI authenticate to Testver’s Gate API. Created — and shown only once — on the Pipelines → CI Tokens tab.
Cloud grid (cloud provider) A remote device/browser farm — BrowserStack, LambdaTest, Sauce Labs, etc. — that Testver can run tests on. Configured under Connectors.
Code Map A structural X-ray of your automation codebase — methods, page objects, callers, orphans, and quality signals. See Code Map.
Connector A configured integration with an external service (JIRA, Slack, Email, a cloud grid, etc.). See Connectors.
Coverage What is and isn’t tested. Flavors:
- Source coverage — % of sources with ≥1 linked test case.
- Automation coverage — % of test cases with a script mapped.
Custom step (AI Record)
A step in a recording that is not an action in the app — “log in with our existing helper”, “read the reset email and keep its link”, “wait until the order ships”. You describe it (with @ pointing at project code or data), and the AI writes the code for it at that position. See Custom Steps.
Cycle One execution attempt of a test plan. A plan typically has multiple cycles (one per environment or round). See Test Plans.
Defect A bug ticket. Created manually or auto-generated from a failed cycle execution. See Defects.
Default provider
The LLM provider Testver uses unless you pick another at conversation time. Marked with a star and a Default badge in Settings → LLM, or set via TESTVER_DEFAULT_PROVIDER.
Delegated execution The model used by the CI/CD Pipelines screen: tests execute on your Testver server while the CI/CD platform only triggers the run and gates the build on the verdict — as opposed to the CI runner installing browsers and running the tests itself.
Environment (run target)
A named entry in Settings → General → Run Configuration — “Staging” — that points a run at an application: a command-line argument (-DbaseUrl=https://staging.example.com) or an environment variable (BASE_URL=https://staging.example.com). See Settings.
Evidence Files attached to a manual cycle execution as proof — screenshots, logs, exports. Each cycle execution has its own evidence list.
Execution (Run) One time you executed tests. Produces a result with passed/failed/skipped counts, a duration, and a status. Listed in Results.
Flaky A test that produces different results on identical code — sometimes pass, sometimes fail. The Dashboard surfaces these.
Folder (test case folder) Hierarchical organisation for test cases. Folders nest and counts roll up.
Framework The test framework Testver detected for your project (Playwright, Cypress, Selenium, WebdriverIO, pytest, etc.). Shown in the header.
Healing (self-healing) Testver’s ability to recover from changed locators. When a recording is generated, Testver writes a healing manifest capturing known-good element context alongside the test; if a locator later drifts, that context is used to re-resolve the element instead of failing outright. There is no separate “Healing” screen — the manifest is written automatically and used during generation and playback.
Incremental Mode (AI Test Gen) A flag telling the AI to skip requirements whose source quote already has matching test cases. Use it after editing a source to cover only the new content.
LLM provider An AI service Testver talks to — Testver (the managed cloud provider, and the only cloud option) or local (Ollama, LM Studio). Configured in Settings → LLM.
Local Browser Connector A per-user mechanism (token-based) that lets Testver drive a browser on your own machine. See Local Browser Connector.
Mapping (script mapping) The link between a test case (in the catalog) and an automation script (on disk). See Script Mapping.
Module A logical grouping of tests, usually a folder. The Dashboard’s Module Distribution shows how tests spread across modules.
Orphan Something that should be linked and isn’t:
- Orphan Test Case — not linked to any requirement/source.
- Orphan Test Script — a mapping whose test case was deleted.
- Orphan Source — a source with no linked test cases.
Output The captured console output of a run (and, for parametrized tests, of each variant). See Output.
Pass rate
The percentage of executed tests that passed in a run: passed ÷ total × 100. Trended on the Dashboard.
Persona An optional attribute on a test case (“Admin”, “Customer”, “Guest”) so coverage can be sliced by persona.
Pipeline mapping A saved rule on the CI/CD Pipelines screen — “when this pipeline triggers, run this suite / cycle / command with these settings”. Its name is the trigger key the CI job passes.
Plan (test plan)
A named scope of test cases for a release/sprint, with an ID like TP-1. Cycles execute against a plan. See Test Plans.
Recording (AI Record) A captured browser or mobile session. Its timeline of clicks, typing, assertions, notes and custom steps — plus any test data and “before the test” setup — becomes input for the AI to generate a test script.
Reverse proxy
An HTTPS front-end (nginx, Caddy, Traefik) placed in front of Testver for a team deployment. It must forward WebSocket Upgrade headers so live updates work.
Role A user’s permission level — Super admin, Admin, Tester, or Viewer. Set on the Users screen. Super admin is the account created at first-time setup; its role cannot be changed and it cannot be disabled or deleted.
Run (Execution) See Execution. One execution of tests; the Runner starts them and Results keeps the history.
Schedule A saved combination of “what to run” and “when”. Triggers runs on a clock, with an overlap guard so a slow run never double-fires. See Schedules.
Session One active login on one device. It stays signed in while you use Testver and ends after a day with no activity or seven days after sign-in (admins can change both). Managed from Profile → Active Sessions; admins can revoke any from Users. See Signing in.
Source Anything that defines what to test — a requirement document, notes, a JIRA ticket, an uploaded file. See Sources.
Strategy (test strategy) A test’s approach — positive, negative, edge case, security, performance, etc.
Suite A test file containing one or more tests. Roughly: suites are files, tests are the cases inside them.
Super admin The top role: the account created at first-time setup. Owns system-level settings and is the only account that can create Admins. Its role can’t be changed and it can’t be disabled or deleted.
Tag A label attached to a test case. Tags are auto-pruned — when no case uses a tag, it’s deleted.
Tester The day-to-day role: can create, edit, and run tests and use AI features, but cannot manage users or read the Audit Log. The right default for most teammates.
Test Case A documented test — title, preconditions, steps, expected results. Manual or automated. See Test Cases.
Trace (Playwright trace)
A .zip recording of a run including DOM, network, and console. View at trace.playwright.dev.
TC ID / TP ID
Human-readable IDs assigned automatically — test cases are TC-1, TC-2; test plans are TP-1.
Variation / Variant One data set of a parametrized (data-driven) test. Testver rolls the variants of a parametrized test up under a single Variations view, each with its own steps and Output.
Viewer The read-only role: can view cases, plans, results, defects, and dashboards, but cannot run, edit, create, or use token-consuming AI features.
Uncategorized Test cases not assigned to any folder. Always shown at the bottom of the folder list.
Workflow A saved, multi-step automation that chains Testver actions together. See Workflows.