Docs/Building your first smoke suite
#

Building your first smoke suite

export const meta = { title: 'Smoke suites', description: 'Build a small, reliable set of must-pass flows to gate every release.', tags: ['guide', 'qa', 'releases'], };

A smoke suite is the fastest way to build confidence in every release: it’s a small set of must-pass flows that cover your most important user journeys.

The goal is not “test everything.” The goal is: “If this is broken, we need to know immediately.”

01Before you start

  • You have a Property for the app/site you want to test.
  • If login is required, you’ve set up Credentials and verified authentication works.
  • You’ve crawled at least once so you have a baseline set of discovered Pages.
  • If you want a faster starting point, use Release QA bootstrap to propose an initial smoke or regression suite from recent code changes, then review and promote the suggested specs on the release timeline.

If you haven’t done these yet, start with Quickstart, then Credentials and login, and Crawling.

If you already have a release in progress, you can also use Release QA bootstrap to seed your first suite quickly, then come back to this guide to refine the flows by hand.

021) Pick the journeys (start with 3–7)

Pick flows that answer: “If this is broken, we need to know immediately.”

Common examples:

  • Sign in / sign out (or session refresh)
  • Create the core resource (project, document, ticket, etc.)
  • A critical payment or billing step (if applicable)
  • Invite a teammate / accept an invite (or role change)
  • A top navigation path that breaks easily (e.g. global search, sidebar switcher)

Keep it small. Aim for 5–15 minutes to run end-to-end.

Tip: if you can’t explain why a flow belongs in the smoke suite in one sentence, it probably doesn’t.

032) Turn each journey into a reliable flow

  1. Start from a stable entry point (typically your property base URL).
  2. Use the Flow Designer to create one flow per journey.
  3. Prefer deterministic actions:
    • Navigate by explicit links/buttons (not raw URL hacks unless you control them).
    • Avoid flaky timing; rely on app-visible states (loaded, success message, new row in table).
  4. Add a clear “done” signal at the end of the flow (e.g. “Order confirmed”, “Project created”).

If you’re unsure what to build first, run Exploratory QA once and turn the best paths into flows.

043) Validate flows with authoring runs

Before you rely on a smoke suite, make sure each flow:

  • Passes consistently across multiple runs
  • Produces useful evidence when it fails (screenshots/traces that show what happened)
  • Fails for real regressions, not for incidental UI churn

When a flow is flaky, fix the flow first. A smoke suite that flakes erodes trust quickly.

054) Run it like a release gate

  • Every release: run the smoke suite right before you ship (and again right after, if you can).
  • Nightly: schedule it to catch regressions early.
  • After major changes: auth, navigation, payments, onboarding.

If the smoke suite fails, treat it as a release blocker until you understand the cause.

06A simple starter template

If you need a starting point, here’s a common 5-flow suite:

  1. Sign in (or session refresh)
  2. Navigate to the primary dashboard/list
  3. Create the primary object
  4. Edit the primary object
  5. Sign out (or switch org/workspace)

07Build your first smoke suite

You can build your first smoke suite in two ways:

OptionWhen to use it
Build by handYou already know the exact must-pass journeys and want full control over each flow.
Use Release QA bootstrap firstYou want to seed an initial smoke or regression suite from recent code changes, then review and promote the proposed specs.

Release QA bootstrap is a fast way to get started when you do not yet have coverage. It reviews recent changes, proposes high-priority specs, and shows them on the release timeline so you can decide what belongs in your suite.

Treat bootstrap output as a starting point, not a replacement for review. Check the proposed journey steps, inputs, preflight notes, cleanup steps, and any skipped coverage before you promote specs into your suite.

After promotion, tighten the suite using the same guidance in this page: keep only must-pass journeys, make each flow deterministic, and validate every flow with authoring runs.

08Next steps

  • If you need a fast first draft, use Release QA bootstrap from a release timeline to seed coverage, review the proposed specs, and promote the ones that match your must-pass journeys.
  • Use Running your first QA audit when you want broader coverage and issue discovery.
  • Read Flows, Runs, and Issues to go deeper on authoring, execution, and triage.