Skip to content
QualityMaxQualityMaxQualityMax Docs

Core concepts

Five ideas the rest of this documentation assumes. Read once, and the reference pages stop needing footnotes.

The hierarchy

Section titled “The hierarchy”

Everything in QualityMax hangs off a three-level structure:

Projects › Test Cases › Automation Scripts

  • Projects — one application under test. A project owns its repository connection, its crawls, its settings, and its history. Everything else is scoped to it.
  • Test Cases — what should be true, written so a human can read it. A test case survives rewrites of the code that checks it, which is why coverage is measured here rather than in script files.
  • Automation Scripts — the executable form of a test case, in a specific framework. One test case can carry several scripts — a Playwright script for the browser path and a pytest script for the API path are two implementations of the same intent.

The split matters when things break. A failing script is a question about the script; a failing test case is a question about the product.

Credits and sandbox minutes

Section titled “Credits and sandbox minutes”

Two meters, commonly confused, measuring different things.

Credits Sandbox minutes
Measures Platform actions you invoke Cloud compute you consume
Spent by Crawls, generation, imports, AI reviews, quality gates, site audits, and test runs Only test runs executed in the QualityMax Sandbox
Shape of the limit A monthly allowance per action type A monthly minute allowance, plus a cap on how many runs go at once

An action is metered wherever it runs, so an execution draws a credit whether it happened in the cloud or on your own machine. Sandbox minutes are the narrower meter: they count only cloud compute, and a local-agent run stays outside that budget entirely. Some plans also make local executions unlimited, which makes the local agent the cheaper path for large or frequently re-run suites.

Your plan determines both allowances, and for accounts that belong to a team the team’s plan takes precedence over the individual one.

Where tests run

Section titled “Where tests run”

Every execution goes to one of two places, and the choice is yours per run.

QualityMax Sandbox — a managed, isolated environment. Nothing to install, no runners to maintain, artifacts collected automatically. Each run is provisioned fresh, so one test suite cannot contaminate the next. Draws down sandbox minutes and respects your concurrency cap.

Local agent — a single Go binary that runs suites on your own hardware, inside your own network. This is the option for applications that are not reachable from the public internet, for compliance regimes that will not permit source or traffic to leave, and for teams who simply already own the compute. Results, artifacts, and status stream back to the platform exactly as sandbox runs do; only the execution location differs.

Neither is a degraded mode of the other. The same scripts, the same reporting, the same evidence.

Pull-request gates

Section titled “Pull-request gates”

When a pull request opens or is pushed to, QualityMax runs four gates in sequence. Each is independent, each is skippable, and each carries its own weight in the merge decision.

Gate What it checks Blocks the merge?
Alpha AI review of the diff, plus a static security scan Yes, on a blocking verdict
Gamma Your repository’s own native test suite Yes, on failure
Delta Test scripts QualityMax generated for this project No — reported as a warning
Beta Browser tests against the deployed preview Yes, on failure

The ordering is deliberate. Alpha is cheap and reads the diff, so it runs first and can fail fast. Gamma establishes that your own suite still passes before anything QualityMax generated is allowed to comment on quality. Delta is advisory by design — generated tests earn trust before they are given the power to block. Beta needs a deployed URL, so it runs last, triggered when the preview environment reports ready.

Gates that find nothing to do skip rather than fail: a repository with no detected native suite skips Gamma instead of blocking on its absence. Gamma and Delta can be turned off per project.

Evidence

Section titled “Evidence”

Execution evidence can include structured results, screenshots, video, browser logs, and Playwright traces. Availability depends on the runner, test configuration, and workflow. Inspect the completed result and the artifacts attached to that execution; a queued job or a generated test is not evidence of a passing run.

The verified-fix workflow can also produce an Ed25519-signed verdict recording repository, base and head revisions, reproduction evidence, and outcome. This is distinct from an ordinary execution result. A valid signature establishes the integrity of the signed record relative to a trusted signer key; it does not independently establish complete coverage or the truth of every observation. See Evidence & Trust for the checks and limitations.

Where to go next

Section titled “Where to go next”