Running your first QA audit

A QA audit is Canary’s comprehensive battle-test of your app. It runs an exhaustive, structured set of checks across your pages, broken down by the elements detected on each page (tables, forms, buttons, inputs, links, etc.).

It’s designed to:

• Execute happy paths and negative tests consistently
• Produce high-quality issues with clear evidence (screenshots, trace, network/console context)
• Give you a report you can use as a release gate and regression baseline

01When to run it

• Before a release (especially after auth/navigation changes)
• After major refactors
• After onboarding a new area of the app
• On a schedule (nightly/weekly) to catch regressions early

02Before you start

• You have a Property for the environment you want to audit.
• If login is required, set up credentials: Credentials and login.
• Crawl recently so Canary has current pages + detected elements: Crawling.

031) Start a QA audit from Runs

1. Go to Runs.
2. Select the Property you want to audit.
3. Create a new QA Run (use crawl-based mode when you want the most comprehensive coverage).

Canary will queue page tests and run structured testing against each page it selects for the run.

042) How structured testing works

For each page in the run, Canary:

• Uses the latest crawl snapshot to identify page elements.
• Matches those elements to a catalog of test templates.
• Generates a pre-populated checklist (a TODO list) like:
  • [Form] Invite teammate - Submit empty form
  • [Data Table] Users - Test sort by column
• Executes all tests, including happy-path and negative checks.
• Files issues when tests fail, with supporting artifacts.

If an interaction reveals new elements (a modal form, a dropdown menu, a new table state), Canary adds additional checks and tests them too.

05Elements Canary detects

Structured testing is based on detected element types:

• Data Table: paginated/sortable/filterable data grids.
• Form: multi-field submission surfaces (create/edit, settings, onboarding).
• Table: static/read-only tables.
• Button: primary actions (save, create, delete, open dialogs).
• Link: navigation and deep links.
• Input: single input controls (textboxes, comboboxes, search inputs, etc.).
• Other: interactive elements that don’t match the types above.

Default tests Canary runs (happy paths + negative tests)

These are the default template tests Canary applies per element type.

Form

• Submit empty form: Verify validation errors appear when required fields are missing.
• Submit with valid data: Fill valid values and verify the submit succeeds.
• Verify required fields are marked: Required fields show indicators and enforce validation.
• Verify optional fields accept empty values: Optional fields can be blank without errors.
• Test field type validation: Email/phone/URL formats validate correctly.
• Test form reset/clear: Reset/clear returns fields to default state.
• Verify submit button disabled state: Disabled while invalid or during submission.
• Test field character limits: Max lengths enforced where applicable.

Button

• Click triggers expected action: Click performs the intended action.
• Verify loading/disabled states: Loading indicator + disabled during async operations.
• Test keyboard activation: Activates with Enter/Space.
• Verify button label matches action: Text matches what it does.
• Test focus visibility: Focus ring/indicator is visible for keyboard users.

Data Table

• Verify pagination controls: Page navigation, page size, indicators.
• Test sort by column: Sort toggles and data order changes correctly.
• Test filter/search functionality: Filters narrow results appropriately.
• Verify empty state message: Clear empty state when no rows match.
• Test row selection: Single/multi-select works (when present).
• Verify data refresh: Refresh updates data from the server.
• Test column visibility toggle: Show/hide columns (when present).
• Verify row actions: Row action buttons/menus work correctly.

Link

• Navigate to correct destination: Click navigates to expected URL/location.
• Opens in correct context: Same tab vs new tab behavior is correct.
• Verify link text is descriptive: Text clearly indicates destination/action.
• Test keyboard navigation: Focusable and activates with Enter.
• Verify visual link styling: Visual treatment (color/underline) is appropriate.

Input

• Accept valid input: Valid values accepted without errors.
• Reject invalid input: Invalid values show errors.
• Test clear field functionality: Clear button/action works (when present).
• Verify placeholder text: Helpful placeholder and correct focus behavior.
• Test character limits: Max lengths enforced where applicable.
• Verify autocomplete behavior: Suggestions work (when present).
• Test copy/paste functionality: Paste works and formats correctly.

Table (static)

• Verify column headers: Headers present and correctly labeled.
• Verify data displays correctly: Cell values match expected formats.
• Test empty state: Empty message when no data.
• Verify responsive behavior: Usable on different screen sizes.
• Test row hover states: Hover feedback is appropriate (when present).

Other

• Verify expected interaction: Primary interaction works as intended.
• Test keyboard accessibility: Reachable and usable by keyboard.
• Verify visual feedback: Clear feedback on interaction.
• Test screen reader compatibility: Properly announced by screen readers.

073) View the full report

To review results:

1. Open the run from Runs.
2. Use the results table to drill into a specific page’s report.
3. Review artifacts (screenshots/trace) and any captured console/network context.
4. Open the Docs Updates tab to review documentation pages created or changed as part of the release.
5. For updated docs pages, review the markdown diff to confirm the release notes and user-facing guidance match the product changes.

If you started a run by mistake or no longer need it, open the run detail page and click Cancel run to stop it.

084) Turn audit coverage into a release gate

Once your audit is stable, take the highest-signal coverage and operationalize it:

• Use the audit results to identify the “must-not-regress” journeys.
• Turn those journeys into Flows.
• Add the top flows to a smoke suite and run it before every release.
• Include the Docs Updates tab in your release checklist so you validate both product behavior and documentation changes before sign-off.

09Next steps

• Read Building your first smoke suite to operationalize your audit into a repeatable release gate.
• Read Runs and Issues for deeper guidance on interpreting results, canceling unnecessary runs, and organizing findings.
• Add docs review to your release validation process so each QA audit includes both test results and documentation verification.