Skip to content
Marriska Docs

How to skip a test you know is broken

When a test fails for a real product bug, you usually don’t want it running every night until the bug is fixed — it’ll just fail every night, mask new failures, and burn your monthly cloud-runs quota. Marking the test as skipped keeps it visible (with the reason) but stops it running.

What skip does

Section titled “What skip does”

When a test is skipped:

  • The runner short-circuits before launching Playwright — no execution.
  • The run report shows the test with an amber SKIPPED badge plus the reason you provided.
  • The test doesn’t count against your cloud_executions_per_month quota.
  • Schedules respect the skip — overnight runs don’t fire it.
  • The skip applies in every test set the test belongs to. Skip is a property of the test, not of any one set.

You can un-skip from the same dialog any time.

When to skip vs. delete

Section titled “When to skip vs. delete”
  • Skip if the test is correct but the product is broken — you’ll re-enable it when the bug is fixed. Skipping preserves the test, the steps, the variables, and the history.
  • Delete if the test is obsolete — wrong assertions, dead feature, duplicated by another test. Deleting removes it permanently.

How to skip a test

Section titled “How to skip a test”

You can skip from three places, depending on where you noticed the problem.

From the Tests page

Section titled “From the Tests page”
  1. Right-click the test in the explorer (or click the … menu).
  2. Pick “Skip…” from the context menu.
  3. Fill in the dialog — see the skip dialog below.

From a test’s own page

Section titled “From a test’s own page”
  1. Open the test by clicking it in the explorer.
  2. Click the amber ⊖ button in the page header (between Duplicate and Delete).
  3. Fill in the dialog.

From a run report — the most common case

Section titled “From a run report — the most common case”

This is the natural moment — you’re looking at a failed test, you realise it’s a product bug, you want to skip it without leaving the report.

  1. Find the failed test in the run’s test list.
  2. Click the ⋯ menu on that row.
  3. Pick “Skip future runs…”. The same dialog opens with the test pre-loaded.

The current run report is unchanged — skip applies to future runs.

The skip dialog

Section titled “The skip dialog”

  1. Pick a category (required) — drives the badge sub-label and the per-org “skip reasons” rollup. Five options:

    • Bug — blocked by a known product bug
    • Flaky — intermittent, needs investigation
    • Environment — depends on something not available right now
    • Work in progress — being written or refactored
    • Deprecated — kept for history but shouldn’t run

  2. Add details (optional) — free-text up to 2000 chars. Shows on the test row + the run report.

  3. Add a ticket URL (optional) — JIRA, Linear, GitHub, anywhere. Renders as an external-link icon next to the reason so anyone reviewing the report can click straight to the tracker.

  4. Set an auto-resume date (optional) — leave empty for an indefinite skip, set a date and the test runs normally again after that date.

Sequential test sets — the cascade warning

Section titled “Sequential test sets — the cascade warning”

If you skip a test that belongs to a sequential test set, the dialog warns you with the affected sets listed. Sequential mode runs tests in order, with each test inheriting the previous one’s browser state — so skipping Login and then running View dashboard will fail the dashboard test, because there’s no logged-in session to inherit.

The dialog offers a one-click Switch them all to independent → button that flips the affected sets to independent mode. Independent mode runs each test from a fresh browser, so skipping doesn’t cascade.

See Independent test sets for the full story.

What you’ll see in run reports

Section titled “What you’ll see in run reports”

The run summary’s Skipped counter is amber (matching the badge color) so it stands out alongside passed and failed counts. The skipped test rows show:

  • Amber SKIPPED · <category> pill
  • Italic reason line beneath the test name
  • External-link icon for the ticket URL if you provided one

If you skip a test that has previously failed, the next run will show the skip instead of a failure — your dashboards stop showing red for something you’ve explicitly opted out of.

How retries interact with skip

Section titled “How retries interact with skip”

In an independent test set with retries_on_failure configured, the runner never reaches the retry loop for a skipped test. Skip wins.

Un-skipping

Section titled “Un-skipping”

Open the dialog the same way you’d open it for a fresh skip. The dialog detects the test is already skipped and shows an Un-skip this test action on the bottom left. Clicking it clears all skip metadata; the test runs normally on the next execution.

Section titled “Related”