Skip to content

Key concepts

Organization e.g. "Northstar Ops" - a company or business unit
└── Project e.g. "Maximo upgrade" - a team's workspace; roles are set here
├── Applications the systems under test ("Maximo", "Customer portal")
├── Environments where an application runs: base URL + variables + secrets
├── Test suites functional areas that group tests ("Purchasing", "Asset")
├── Test cases the tests themselves: ordered steps, versioned
│ └── Steps Open, Type, Click, Exists, For each, HTTP request, …
├── Components reusable, versioned step sequences ("Login")
├── Test data data sets (tables, CSV, Excel) and data pools
└── Runs every execution: step results, screenshots, row results

Everything inside a project is visible only to that project’s members.

Concept What it is Where
Organization The top level. Its administrators manage projects and people, and are Admin in every project. Sidebar → organization switcher, All projects, Org members
Project A team’s workspace. Each member has one role per project (Admin, Test Manager, Test Developer, Tester, Viewer). Sidebar → project switcher, Project members
Application A named system under test, with its type (Web, Android, iOS) and browser. Environments link to it. Applications
Environment One copy of an application: baseUrl and other variables, plus secrets (credentials). A test never contains addresses or passwords; it refers to the environment’s. Environments, Secrets
Test suite A label that groups tests by functional area for filtering and dashboard statistics. Test Suites
Test case An ordered list of steps, plus settings (defaults, variables, data source). Stored as JSON (the DSL), with numbered versions: a Draft is edited in place, and a Ready version is frozen. Test Cases
Step One action or check: open a page, type, click, assert, loop, call an API, run custom code. Steps that act on the page have a target (how to find the element). Test editor
Component A sequence of steps published as an immutable, versioned building block, with parameters. Tests call a pinned version. Components
Test data Data sets (tables, CSV or Excel uploads) and data pools (single-use records that runs lease). Drive a test once per row. Test Data
Run One execution of a test against an environment: status, step results, screenshots, extracted variables, and per-row results for data-driven tests. Test Runs

Tests are data, not code. A test is a JSON document in a fixed format (the DSL). The editor, the server, the command line and the runner all read the same format. You can view it in the editor’s DSL tab.

Nothing saves by itself. Edits stay local until you choose Save. Leaving the page with unsaved edits asks first. A run always executes the saved version.

Ready tests are frozen. A test moves from Draft to Ready to Deprecated. A Ready version cannot change. To change it, you start a new revision, which begins as a Draft copy. Runs therefore always point to a definition that still exists.

Elements are found by several strategies, in order. Each target carries an ordered list of ways to find the element (id, label, role, text, CSS, XPath…). If the first stops working and a fallback succeeds, the step passes with a warning (degraded), so you learn about drift before the test breaks. See Element targets.

Secrets are never visible. A secret value is written into the browser only at the moment of use and masked in every log, screenshot caption and report.

Variables come from scopes. {{name}} is looked up from the narrowest scope outward: loop variables → runtime (set by earlier steps) → test variables → environment variables. {{secret.NAME}} and {{data.column}} are reserved prefixes. See Expressions and variables.

A missing variable is an error, not an empty string. A typo in {{custmer}} fails the step with a named error instead of silently typing nothing and passing.

→ The test editor