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.

​

Arrange-Act-Assert (AAA)

Arrange-Act-Assert is the format QA Wolf flows follow. The tests inside a flow divide into three parts:

• Arrange — sets up state before the interaction.
• Act — performs the interaction being tested.
• Assert — verifies the expected outcome.

See Anatomy of a flow for how this looks in flow code.

​

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 so a trigger can run them together, and so a Run Rule can order or co-schedule every flow carrying it. 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, defined in your repository’s rules.yaml, orders flows (run-after, run-before) or co-schedules them (run-with, run-without). A rule names flows or tags. By default, if an earlier flow fails, the later flows are marked failed without running, to keep the failure list focused on the root cause. See Run Rules.

​

Schedule

A schedule is a trigger that runs a set of flows hourly, daily or weekly in one environment. Hourly and daily schedules can be limited to chosen days of the week. To run flows when a build deploys, use a deployment trigger instead. See Triggers.

​

Trigger

A trigger runs a set of flows when your application deploys, or on a schedule. Triggers belong to the workspace, so one trigger can cover every environment a deployment reaches. The flows are named directly, selected by tag, or chosen by QA Wolf as a Smart Smoke Suite. See Triggers.

​

PR testing

PR testing runs your flows on every pull request, against its preview deploy, and reports the result on the pull request: as checks on GitHub, and as a commit status on GitLab. It requires a connected GitHub or GitLab integration covering the deploying repository. See PR testing.

​

Smart Smoke Suite

A Smart Smoke Suite is a set of flows QA Wolf selects from the pull request behind a deploy, rather than a set you name in advance. When no flow is affected, no run starts. See Smart Smoke Suites.