Skip to main content
A test case describes a behaviour you want Qlane to verify. It’s written in plain English, not code. You don’t write selectors or assertions — the agent figures out how to perform the steps against the running app.

​
Lifecycle: draft → active → archived

Test cases move through three states:
  • Draft. Either AI-drafted from a PR diff or hand-written. Drafts are visible but don’t run as part of normal sessions.
  • Active. Runs on every applicable session.
  • Archived. Hidden from new sessions. Past sessions still show their result.
The transition from draft to active is always a human action. Drafts only become active when you accept them — usually by clicking “Accept” on the proposal, or by merging the PR that introduced them.

​
How drafts get generated

Qlane drafts test cases in two situations:
  • From every PR diff. When a PR is opened, Qlane reads the diff and proposes test cases for the new behaviour. Drafts show up in the project’s Test cases tab marked with the PR they came from.
  • From a baseline exploration. On first project setup (and on demand), the agent explores your app and proposes a smoke suite — “sign in works”, “create a project works”, “invite a teammate works”. These show up the same way.
Drafts that don’t get accepted simply expire — they never enter your active suite.

​
Writing a test case yourself

Open Test Cases in the project sidebar and click New test case. To add a case to a feature area, click the + beside that area instead; the area is filled in for you.
  1. Title — required. What the case checks, in one line.
  2. Feature area — pick an area, or choose New area… and name it. Left empty, the case is Uncategorized.
  3. Suite — Smoke, Sanity (the default) or Regression. See Suites.
  4. Priority — Critical, High (the default), Medium or Low.
  5. Draft the steps with qlane (optional) — switch it on and fill in Description for qlane. Qlane writes the case’s description, preconditions, steps and coverage from it.
Click Continue (or Continue and draft steps). The case opens in the editor:
  • A description of the behaviour the case proves (optional).
  • Test steps — Preconditions, then each step’s Action, Expected result and Test data (optional), then Postconditions.
  • Properties — Priority, Suite, Type, Feature area and Estimate.
  • Coverage — Routes, Components and Flows. Qlane runs the case on pull requests that change any of these.
Click Save test case. A case needs a title and at least one step with an action and an expected result. Nothing is created until you save.

​
Suites

Suites signal what kind of failure each test catches:
  • Smoke — the app is alive. On pull requests, Qlane runs every active Smoke case after the pull request’s own cases.
  • Sanity — primary user flows. Most of your active suite lives here.
  • Regression — narrow tests pinned to specific past bugs. They guard against re-introductions.
Qlane picks a suite for the cases it proposes from a pull request. You can change it any time under Properties.

​
Editing and versioning

Editing a test case applies to all future runs. Past session reports show the version of the test case that was in effect at the time, so historical results remain reproducible.

​
Writing tests the agent runs well

A few patterns work well:
  • One outcome per case. “Sign in and create a project” should be two cases — failures are easier to diagnose.
  • Describe the user’s intent, not the UI. “Sign in” beats “Click the green button labelled ‘Sign in’” — the latter breaks the moment you rename the button.
  • Reference real fixtures. “Sign in as qa@example.com” is more reliable than “Sign in as a test user.”
  • Lean on preconditions. Don’t make the test create its own scaffolding if a precondition can pin it.

​
Promotions and demotions

Accepted test cases aren’t immutable. The agent watches how each one performs across sessions and surfaces proposals:
  • Promote a frequently-passing sanity test to smoke, if it covers a critical path.
  • Demote a frequently-flaky case to regression so it doesn’t gate merges.
  • Archive a case that’s been duplicated by a newer one.
You approve or reject each proposal — promotions and demotions are never silent.