QA Settings
Choose how much testing a project gets — how deep test cases go, whether Fabric drafts them at all, which environments runs target, and how often CI results are pulled in.
Not every project needs the same testing. A prototype and a regulated production system both benefit from test cases, but asking for security and end-to-end coverage on a two-week spike wastes effort and credits. Fabric's QA settings let you set that level once per project, and everything downstream follows it.
Two pages hold the configuration, both under Project ▸ Settings:
- Testing — the QA policy: depth, evidence, sceptic roles, result sync.
- Environments — the deployed targets a Fabric-driven run can point at.
Can't see these pages? Both are part of the QA feature and appear only when it's enabled for your deployment. If Settings ▸ Testing is missing entirely, the QA feature is switched off — ask whoever administers your Fabric instance to enable it. This is the first thing to check when a project looks like it has lost its QA configuration.
Decide whether Fabric writes test cases at all
Three switches sit at the top of Settings ▸ Testing, under Test-case generation. They decide whether test cases are generated, when in a feature's life that happens, and what Fabric does when one fails. All three save immediately — unlike the policy below them, which is a draft until you press Save.
| Switch | Default | What it does |
|---|---|---|
| Generate manual test cases | On | Fabric drafts test cases from a feature's acceptance criteria |
| Apply TDD approach | Off | Test cases are written before implementation, and the requirements are reviewed against them |
| Open bugs for failing tests | Off | When your CI reports a linked case as failing, Fabric opens a bug for it automatically |
"Open bugs for failing tests" opens at most one bug per case. A case that keeps failing does not accumulate duplicates, and a bug that is already open is not reopened. Leave it off if you would rather triage failures yourself from the Runs segment and promote only the ones worth tracking.
Turning Generate manual test cases off stops the drafting entirely — no cases are produced and no credits are spent on them. Everything else in the QA tab keeps working: you can still author cases by hand, sync them, and read CI results.
Apply TDD approach changes the order of the feature lifecycle:
Default order (TDD off)
Requirements are generated, the feature is implemented, the feature is reviewed against its requirements, and then test cases are drafted from the finished specification.
Test-first order (TDD on)
Test cases are drafted straight after the requirements — before any implementation. The requirements are then reviewed against the flows those cases describe, which is where test-first earns its keep: writing the cases exposes gaps in the specification while it is still cheap to fix them.
After implementation
With TDD on, the feature review considers both the requirements and the test cases, and the cases are then updated to match the flows that were actually built.
Set the testing depth
Strategy & depth is the single most consequential choice on the page. It decides two separate things: how thoroughly Fabric explores each acceptance criterion, and which kinds of test case it may write at all.
| Depth | What gets written |
|---|---|
| Easy | Functional / acceptance cases only — the happy path and the key negative case. No integration, end-to-end, security, performance or accessibility cases. |
| Average | Functional, integration and end-to-end cases, covering the main negative paths and obvious edge cases. Security, performance and accessibility only where an acceptance criterion explicitly calls for them. |
| Hard | Everything above, plus security cases (auth, tenant isolation, injection, data leaks), accessibility cases (keyboard navigation, labels, contrast), boundary values, concurrency and tenant-isolation cases. |
Easy really is lighter. The depth is stated to the AI as an exclusion as well as an inclusion — an Easy project is told not to reach for end-to-end or security cases on its own initiative, even where they would obviously add value. That is the point: a lighter tier is a deliberate choice about cost and scope, not an oversight for the AI to correct.
A sceptic role overrides the depth. Depth and sceptic roles are separate controls that both decide what gets written. If you set Easy depth but leave the Security Reviewer enabled, you still get security cases — an enabled role is read as a deliberate exception to the tier, not a conflict. To make a tier genuinely narrow, turn off the roles you don't want along with it.
If a case turns up outside its tier, it arrives as Proposed. On an Easy project, an integration or end-to-end case the AI wrote anyway is created as Proposed rather than Draft — visible and reviewable, but not counted towards your coverage until you accept it.
Nothing is thrown away, and nothing joins your suite unasked. Cases a sceptic role produced are exempt: enabling that role is what asked for them.
Depth applies to newly drafted cases. Changing it does not rewrite cases you already have, and it takes effect on the next drafting run — there is nothing to restart.
Each drafted case also arrives tagged with the level of the test pyramid it sits at — unit, integration, end-to-end, or manual — so the coverage matrix is populated without anyone classifying cases by hand. Where the AI declines to say, the case shows as Unset and you can set it yourself.
There is a second depth setting, and it is not this one. Settings ▸ AI Assistant has a QA strategy level (Light / Standard / Strict) that controls how deep a generated QA Strategy document and the per-feature QA analysis go. The depth on this page controls test-case drafting. They are separate settings for separate artifacts — changing one does not change the other.
Tune the rest of the policy
Everything below the depth selector is a draft until you press Save, and Discard returns you to the last saved values.
Evidence policy
What proof a run must capture before a verdict is recorded: Screenshot required (the default), Optional, or None.
Sceptic roles
Adversarial reviewers that add extra cases during planning, each with its own lens — Security Reviewer, UX Skeptic, Performance Critic, Accessibility Auditor, and Edge-Case Hunter. All five are on until you change them. Cases they contribute arrive as Proposed, so nothing enters your suite without review.
A role you enable applies at any depth, and wins over the tier's exclusions. Since all five start enabled, a new project set to Easy still gets security, performance and accessibility cases until you turn those roles off — which is the single most common surprise on this page.
Coverage target
The percentage the coverage rings on the QA tab are measured against. Defaults to 80%.
Devices and browsers
The viewport and browser a Fabric-driven run uses. Defaults are 1920×1080 (with 1366×768 as a second option) and Chromium; Firefox and WebKit are available. The first entry in each list is the one a run uses.
House rules
Free-text rules and implementation notes handed to the runner before it drives a case — anything it should know that isn't in the test case itself.
The device, browser and environment settings are defaults, not constraints. A run that names its own browser, resolution or environment wins; the stored value only fills the gap.
Control how often CI results arrive
Automatic result sync decides whether Fabric pulls test results from your connected CI on its own, and how often — every 15 minutes (default), 30 minutes, 1 hour, or 4 hours.
Turning it off does not remove the manual path: Sync now in the QA tab always works. The interval is a floor, not a rival schedule — Fabric will not check more often than you allow.
Intervals are offered as a fixed set rather than a free-text schedule on purpose. A cron box invites * * * * *, and a project quietly overwhelming its own CI provider's API is a worse outcome than a slightly staler result.
Add an environment
Settings ▸ Environments holds the deployed targets a Fabric-driven run can point at — typically a staging or test deployment.
Create the environment
Give it a name and the base URL Fabric should open.
Add sign-in credentials (optional)
If the environment needs a login, store the sign-in URL and credentials. Fabric holds these encrypted and injects them into a run without ever writing them into generated scripts, logs, or run history.
Pick a default
Set one environment as the project default so a run that doesn't name a target still knows where to go. Deleting that environment degrades the project to "no default" — it never cascades into your QA policy.
Point Fabric at test and staging environments. A Fabric-driven run performs real actions against whatever URL you give it — it fills forms, clicks buttons, and submits data.
Next Steps
Test Cases
Author test cases with ordered steps, sync them to your PM tool, group them into plans, link them to the work they verify, and let the project AI use them as context.
CI Test Results
Pull automated test results from GitHub Actions, GitLab CI, and Azure DevOps into Fabric, link them to your test cases, and see what broke without opening your CI dashboard.