Test Automation with Playwright or Cucumber · Replay, Live Runs, Nodes

One choice, per project

Two ways to write a test.

A project's framework is set when it's created and can't change afterwards, so the repo stays consistent. Everything past that point (running, reporting, replay, nodes) is identical.

Playwright

Write tests in Playwright's own API and its test runner executes them, driving Chrome or Firefox for real with the auto-waiting that keeps runs stable.

Cucumber

Write Given / When / Then in a .feature file. That file is the spec and the test at once, with no separate script to keep in sync.

01 · Author

Tests, detected from your repo.

Point Plum at your project's test folder. It reads your test files (.spec for Playwright, .feature for Cucumber) and lists every test, grouped by suite. A Cucumber project shows each scenario's Gherkin steps inline. Change something in code and the list updates on its own.

@TS-001@TC-004tags & suites

Plum Automated Tests page for a Playwright project, listing a suite's spec tests

02 · Run

From the browser, or from CI.

The run bar sits at the bottom of every page: type a tag, pick a browser, set how many run in parallel, choose which runner, and go. The same run triggers from the CLI in your pipeline, so a per-run base URL can point each pull request at its own preview.

Plum reports list showing run history and an overall pass rate

03 · Report

Every step, every timing.

A run finishes into one readable report: pass or fail, each test, each step with its result and duration, and the run logs. A test that failed then passed on retry is marked flaky so it doesn't hide in a green run.

A Plum report for a Playwright run, a passed test expanded to its steps

04 · Replay

Watch the run back, not a video of it.

Plum records the page itself as the test runs: the DOM at every moment, not a screen capture. Scrub the timeline, or click a step in the rail to jump straight to it. When something failed, you see the exact state the browser was in.

DOM capturestep markers0.5× / 1× / 2×

Plum session replay for a Playwright run, a step rail on the left

05 · Inspect

Click any element, get a locator.

Turn on the inspector inside a replay and click anything on the recorded page. Plum shows the element's markup and a ranked list of ways to target it (data-test, role and name, CSS path, XPath), with the sturdiest one marked recommended, in Playwright's own order of preference. Copy it straight into a step.

Plum element inspector listing ranked locators for a clicked element, with data-test marked recommended

06 · Live

Watch it happen in real time.

Open a run while it's still going. The browser viewport streams live next to the test output as it prints. If a run has gone wrong, cancel it from here without waiting for a timeout.

live viewportstreaming logscancel mid-run

Plum live run page streaming the browser viewport next to live test output

07 · Scale

One server, as many machines as you need.

Runs use the built-in runner on the server by default. Register runner nodes on other machines and Plum distributes runs across them: a node on Windows, a node closer to your staging environment, a beefier box for the big suites. The queue serialises per node, so nothing steps on anything else.

self-hostedper-node queueschedule with cron

Plum runners settings showing a registered node with latency and controls

08 · Automate

Hand the loop to an AI agent.

Plum has an MCP server built in. Point Claude, Cursor or any MCP client at it with a per-project key and it does what you do in the UI: write test cases and steps, trigger a run, poll it, then read back the report, the scenario detail and the logs.

The key carries your role and stays scoped to one project. Everything the agent creates or runs is tagged (MCP), so it's all auditable.

run_testsget_report_summaryper-run base URL

mcp.json

{
  "mcpServers": {
    "plum-checkout": {
      "type": "http",
      "url": "https://plum.example.com/mcp",
      "headers": {
        "Authorization": "ApiKey plum_live_…"
      }
    }
  }
}

The whole loop

Author, run, and read the result.

A test is a Playwright spec, or plain Gherkin; the project decides. Either way Plum runs it, records the page, and gives you the replay, the locators and the report, all from the same screen.

Get started →

checkout.spec.ts

test("customer completes an order", async ({ page }) => {
  await cart.addItem(page);
  await page.getByRole("link", { name: "Checkout" }).click();
  await checkout.payWithValidCard(page);
  await expect(page.getByText("Order confirmed")).toBeVisible();
});

checkout.feature

Feature: Checkout

  Scenario: Customer completes an order
    Given the user has an item in the cart
    When they proceed to "checkout"
    And they pay with a valid card
    Then the order is "confirmed"

Pick a framework. Plum runs it.