Glossary

​

Workspace

A workspace is the top-level container in the QA Wolf platform. All environments, groups, and related settings live inside a workspace.

​

Environment

Under each workspace is an environment, which corresponds to a specific version of your app, such as development, staging, or production. Each environment can be configured with separate variables (e.g., base URL, users, etc.), concurrency rates, and other settings relevant to the version of the application you’re testing. Flows and tests are unique for each environment and not shared between environments.

​

Flow

A flow is a sequence of tests that validates a user journey in your application. Flows are the primary unit of end-to-end testing in QA Wolf. Flows can be run individually, scheduled, and tagged.

​

Test

A test verifies a specific behavior or step in your application. Multiple tests combine to form a flow that validates a complete user journey.

​

Coverage outline

A coverage outline is the set of groups and flow stubs that define what needs to be tested in an environment. Outlining is the act of producing one: you point the agent at your application, it explores, and it proposes the groups and flows that represent the main areas and user journeys. An outline records scope — it does not contain test code until the flows are created.

​

Coverage map

The coverage map is the visual representation of a coverage outline. It shows the flows in an environment and how they are organized into groups, so you can see the shape of your coverage and find gaps in it.

​

Run

A run is an execution of one or more flows. Each flow is attempted up to three times per run if it fails. Runs can be started manually, invoked automatically by a schedule, or triggered by a deployment. The status and results of every flow in a run are recorded and reported back.

​

Run status

A run ends in one of three states:

• Completed — all flows in the run have passed or been marked as not needing investigation
• Needs investigation — one or more flows failed and have not been marked as resolved
• Canceled — the run was canceled mid-execution by a subsequent run matching the same branch and environment

A failed flow is considered resolved once it passes on a subsequent attempt, the flow itself is fixed and republished, the underlying application issue is fixed, or a maintenance report is filed against it (which excludes the flow from runs until it’s fixed).

​

Environment status

An environment’s status reflects the health of its most recent runs, and is driven by bug priority:

• Ready — all flows passing
• Needs investigation — one or more flows failed, or a medium/low priority bug has been reported against a flow
• Failed — a high or urgent priority bug has been reported against a flow

​

Attempt

Within a run, a flow may be attempted multiple times. As a tester, you will occasionally have flows that flake — attempting to run a failed flow multiple times ensures that the failure is not a temporary fluke. QA Wolf will attempt to run a flow up to three times: the first attempt runs all flows concurrently, the second retries failures in batches of five, and the final attempt runs remaining failures serially (reducing concurrency further isolates whether an environment issue is at fault). Each attempt has its own video, logs, and results.

​

Tag

A tag groups flows for scheduled runs and controls execution order in run rules. Tags are intended to express run intent (test type, expected duration) rather than application structure — QA Wolf runs with full concurrency by default, so organizing flows by feature area rarely adds value.

​

Run Rule

A Run Rule controls the order flows run in by defining a before set and an after set of flows, selected by name, group, or tag. By default, if a flow in the before set fails, flows in the after set are skipped rather than run, to keep the failure list focused on the root cause.

​

Schedule

A schedule defines when and how often runs occur automatically. Scheduling is limited to flows. Individual tests can be run manually for debugging, but they cannot be scheduled independently.

​

Trigger

A run can be started four ways: manually, on a schedule, from a deployment webhook, or from a CI pull-request button. Of these, only schedule-based triggers are self-serve — deployment and PR-based triggers require setup from QA Wolf.