--- title: "Best Test Reporting Tools for Playwright in CI, Compared" description: "The best test reporting tools for Playwright in CI, judged on shard merging, traces, flake history and PR context, and which fits your team." canonical: "https://currents.dev/posts/best-test-reporting-tools-for-playwright-in-ci-compared" updated: "2026-11-10" --- # Best Test Reporting Tools for Playwright in CI, Compared Published 2026-11-10 by Walter Galvão. Canonical URL: https://currents.dev/posts/best-test-reporting-tools-for-playwright-in-ci-compared The best test reporting tools for Playwright in CI, judged on shard merging, traces, flake history and PR context, and which fits your team. --- > **TL;DR** > > This article covers test reporting tools for a Playwright suite in CI. It judges each tool on failure traces, per-test history, sharded runs combined into one run, pull request context and live results. It compares Currents, Allure Report, Allure TestOps, BrowserStack Test Reporting & Analytics, Qase, Testomat.io, Katalon TestOps, Azure DevOps Test Reporting and Xray, and says which team each one fits. > > If you run a sharded Playwright suite in CI and want one run per build, each test's flake and duration history, pull request context and live results, start with Currents. For a report you own, with history, pick Allure Report; if your tests live in Jira, pick Xray; and for a small suite on one machine, Playwright's HTML reporter is enough. > > 1. If you run a sharded Playwright suite in CI and want one run per build, each test's history, pull request context and live results, start with Currents. > 2. For a small suite on one machine, use Playwright's HTML reporter, plus blob reports if you shard. > 3. For a report you own, with history, pick Allure Report. > 4. If your tests live in Jira, pick Xray. > 5. If you already run on a platform, use its tool. Shard a Playwright suite across CI machines and a red build leaves a report on every shard. Each report says what failed on its own machine. None of them says what failed in the build. Playwright's [blob reports](https://playwright.dev/docs/test-sharding) exist mainly to fix that: they hold every test, result and attachment of a shard, and you merge them into one report afterward. Merging gives you one combined report of all the shards' results for that build. Playwright [labels a test flaky](/posts/playwright-flaky-tests-detect-them-in-ci-with-retries) when it fails on the first run and passes on retry. The [HTML report is a self-contained folder for one test run](/posts/playwright-html-reporter-why-it-breaks-down-at-scale), so its flaky label covers that run alone. A test that flakes on Tuesday and again the following Monday leaves two flaky labels in two reports that nobody opens side by side. A per-run report answers one question: what failed in this build? The questions that eat an afternoon in CI are different. Has this test failed before? Since when? On which pull request? Answering them takes a tool that keeps results across runs, and the right one depends on how your results reach it and what it does with a sharded build once they arrive. ## How we picked Every tool here starts where Playwright stops. Playwright Test ships [several built-in reporters](https://playwright.dev/docs/test-reporters) and supports [custom ones](/posts/playwright-custom-reporters-build-your-own), built as a class that implements some of the Reporter API methods. The HTML reporter writes a self-contained folder for one test run that you can serve as a web page. The JUnit reporter writes a JUnit-style XML report. A blob report holds every test that ran, its result and its attachments, traces and screenshot diffs included, and blob reports can be merged and converted to any other Playwright report. Playwright Test can also run more than one reporter at the same time, so a tool's reporter can run next to the HTML report instead of replacing it. If Cucumber drives your tests, don't count on that baseline. A team running Playwright with Cucumber asked for step-wise information in the HTML reports generated by Playwright ([#36115](https://github.com/microsoft/playwright/issues/36115)). A maintainer replied that there are no Cucumber HTML reports in Playwright. The reporter said they generate their HTML reports with third-party tools. ### Three routes in Results reach a reporting tool in one of three ways: - A reporter package that you add to `playwright.config.ts`. - A JUnit XML file from Playwright's JUnit reporter, imported through the tool's API. Azure Pipelines' Publish Test Results task reads JUnit format by default. - A CLI that you put in front of the command you already use to start a test run. The route is most of the setup cost. A reporter package is a config change. A CLI wrapper changes the command every shard runs. ### Five criteria 1. Does the tool show [the failed test's trace](/posts/playwright-trace-viewer-debug-ci-failures-step-by-step), screenshots and video next to the error? Playwright's docs recommend `trace: 'on-first-retry'` on CI, which produces a `trace.zip` file for each retried test. A tool should open that file for you. 2. Does it keep each test's results across runs, so flaky tests and slowing tests show up? 3. Does it combine the parallel or sharded jobs of one build into one run? 4. Does it tie a run to its commit, branch or pull request, and group failures by error? 5. Does it show results while the run is still going? Those five questions cover what a test report has to show (pass and fail, flaky tests, trends, failure details) in terms you can check against a tool's docs. Prices stay out of this list. So do test frameworks, CI servers and device clouds: every tool here takes results from a Playwright suite you already run. ## Currents ![Currents homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/currents-homepage.jpg) [Currents](https://currents.dev/) is our product. It collects Playwright results across CI machines and workers in a cloud dashboard, and it uses the CI build ID to assign the results to a run. ### Sharded runs Each shard runs the same `pwc` command with its own `--shard` value and an identical `--ci-build-id`. On the first machine: ```bash npx pwc --ci-build-id build-1234 --shard=1/2 ``` On the second: ```bash npx pwc --ci-build-id build-1234 --shard=2/2 ``` In a real pipeline, take the build ID from a value your CI gives every job of the same build, so all shards agree on it. You don't split spec files by hand: by default, Playwright [assigns entire test files to shards](https://playwright.dev/docs/test-sharding), and it runs them in parallel in worker processes. Shards that use the same CI build ID report into the same run, so you have no per-shard reports to merge after the build. ### Live results The Currents reporter streams each step's results and lifecycle events as soon as they are available. Streaming pays off on the worst builds: when an execution crashes, Currents still captures the step that caused the failure. ### Failure artifacts Currents uploads generated artifacts to cloud storage as soon as they exist, so they stay accessible even when the execution crashes. A shard that dies halfway still leaves behind the artifacts it had already generated. ### Per-test history Test Explorer is where you find flaky, failing and long-running tests, and the trends in how tests behave. Its Duration Trend compares a test's average duration across two equal periods, such as the last 30 days against the previous 30. That comparison catches the test that gets a little slower every week. Clicking a test opens its history of executions, performance metrics and top errors, which answers "has this failed before, and how?" without opening old reports. ### Pull request context The Pull Requests page lists one row per pull request that CI reported runs for in the selected date range (the last 30 days by default), with its latest run's status and its recent runs. Each run shows its commit message, commit author, short SHA, failed test count, duration and creation time. The page answers which open pull requests are failing, and since when, without scanning the flat run feed. ### Who it fits Currents fits teams that shard a Playwright suite across CI machines and want one run per build, each test's history and pull request context in one place. If your suite runs on one machine and nobody asks about last week's failures, Playwright's HTML report is enough. Against the five criteria, this entry shows three in full: every shard in one run, results streamed during the run, and each test's flake and duration history. It shows two in part. Error Explorer shows the top errors in your Playwright CI runs and lists the tests each error affected. For a failed test attempt, the dashboard shows the error message and the exact source line, and its traces open directly in the Playwright Trace Viewer. Those three criteria in full, plus the pull request context, make Currents the place to start for a sharded Playwright suite in CI. ## Allure Report ![Allure Report homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/allure-report-homepage.jpg) [Allure Report](https://allurereport.org/) is a test report that lets you move between runs of the same test, across reports through Tests history and within one report through Retries. Playwright results reach it through the Allure Playwright reporter, which you add to `playwright.config.ts`. Traces get proper handling. With Playwright's tracing enabled, Allure Playwright attaches the trace file to the test result, and the trace opens from the report in Playwright's Trace Viewer instead of downloading as a plain zip. For a pipeline with several test runs, Allure Report can build one report from a dump archive saved by each stage. Each stage of a pipeline with several test runs can save a dump archive, a zip with all of its run data, and Allure Report then builds a single report from the [collected archives](https://allurereport.org/docs/multistage-builds/). Your CI has to gather the archives from every shard before the report step runs. Flaky detection depends on history. Allure Report adds a Flaky mark to a test automatically from the test's history, and history must be enabled for the mark to appear. Allure Report fits teams that want per-test history and flaky marks in a report their own CI builds, and who will wire archive collection into that CI. Pick something else if you won't keep history between runs. ## Allure TestOps ![Allure TestOps homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/allure-testops-homepage.jpg) [Allure TestOps](https://qameta.io/) detects flaky tests without any configuration. It marks a test flaky when at least 3 status transitions occur within its 10 most recent executions, so a test that goes pass, fail, pass, fail inside that window gets flagged. Allure TestOps' docs show Playwright tests importing the allure API from the `allure-playwright` package. In CI, `allurectl watch` runs your test command and streams its results to Allure TestOps in one step. Sharded suites fit its model. When a pipeline execution has several jobs, all of them report to the same job run inside a [single launch](https://docs.qameta.io/allure-testops/briefly/launches/), so the shards of one build stay together. Allure TestOps fits teams already on Allure who want flaky detection they don't have to configure, with every shard of a build in one launch. Pick something else if a per-run report is all you need: a separate service is overhead for a small suite on one machine. ## BrowserStack Test Reporting & Analytics ![BrowserStack Test Reporting & Analytics homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/browserstack-test-reporting-analytics-homepage.jpg) [BrowserStack Test Reporting & Analytics](https://browserstack.com/) analyzes every error occurrence in a build run and groups similar failures, so you debug the unique causes instead of every occurrence. When one broken login fails a whole folder of tests, you look at one cause. The route is a prefix. You put `browserstack-node-sdk` in front of the command you already use to start a run, and the SDK sends the data automatically: ```bash npx browserstack-node-sdk playwright test ``` The [Playwright integration](https://www.browserstack.com/docs/test-reporting-and-analytics/getting-started/javascript/playwright/integrate-your-tests) needs a test suite on Playwright 1.31 or later, and your tests don't have to run on BrowserStack's infrastructure. For failure artifacts, Timeline Debugging puts logs from the framework, screenshots, the browser's JS console, the network and the backend application on one timeline, with a video of the execution. If you would rather not change the test command, you can also import JUnit XML reports through an API. BrowserStack Test Reporting & Analytics fits teams already on BrowserStack, and teams whose CI failures cluster into a few repeated errors. Pick something else if your suite is pinned below Playwright 1.31, which the SDK route doesn't support. ## Qase ![Qase homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/qase-homepage.jpg) [Qase](https://qase.io/) receives Playwright results through the `playwright-qase-reporter` package, which uploads a run's results to a Qase project through Qase's public API. To collect every shard's results in one Qase run, create the test run in a separate step before any tests run. Create one run, give its ID to every shard, and the results of four Playwright shards land in a [single test run](https://developers.qase.io/docs/parallel-test-runs-and-sharding) instead of four. With smaller batch sizes, a long-running suite's results appear in Qase during execution rather than all at once at the end. In CI, put the branch name, build number or commit in the run title, so every run in Qase points back at the build that produced it. Qase fits teams that keep test cases in a manager and want automated CI results next to them. Pick something else if you don't want a pre-run step, since the single run for all shards depends on creating the run first and passing its ID to every shard. ## Testomat.io ![Testomat.io homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/testomat-io-homepage.jpg) [Testomat.io](https://testomat.io/)'s framework docs tell Playwright users to add its reporter to the Playwright config. A Playwright trace uploaded to a run opens in Playwright Trace Viewer, where you can step through the run. By default, when you split tests across parallel jobs, each job reports separately in Testomat.io. Once you configure a shared run, all parallel CI jobs report into [one run](https://docs.testomat.io/tutorials/playwright/). The `@testomatio/reporter run` command creates an empty run and passes its ID to every spawned process, so however many processes start, they all report to that run. Testomat.io fits teams that want test management and Playwright traces in the same place. Pick something else if nobody on the team manages test cases: a test management tool is a lot to adopt for engineers who only need to see why a CI build failed. ## Katalon TestOps ![Katalon TestOps homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/katalon-testops-homepage.jpg) [Katalon TestOps](https://katalon.com/) puts Playwright results in the same Test Runs list and reports as Katalon Studio results, so a team running both reads one set of runs. ![Katalon's Test Result Details page for a test run](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/katalon-testops-product.jpg) *Katalon's Test Result Details page for a test run. Image: [Katalon TestOps](https://docs.katalon.com/katalon-platform/analytics/test-results-failures/investigate-failures).* The route leaves your pipeline as it is. A team that has its own [GitHub Actions or Jenkins pipeline](https://docs.katalon.com/katalon-platform/integrations/testing-framework/playwright-integration) keeps it and adds only the `@katalon/playwright-reporter` package, and the results, history and analytics land in the Katalon platform. History sits on the test run itself. The Tests tab of the test run detail page shows a trend line of the same test's past results. Look there first after a red build. One failure in a long green streak calls for different work than a test that has failed for days. Screenshots and videos come from the same test run details page: when you investigate a failure, you go back there and review its images or videos for visual clues. Katalon TestOps fits teams running Katalon Studio and Playwright side by side who want one place for both. Pick something else if your suite is Playwright-only and nobody uses Katalon Studio. ## Azure DevOps Test Reporting ![Azure DevOps Test Reporting homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/azure-devops-test-reporting-homepage.jpg) [Azure DevOps Test Reporting](https://microsoft.com/) is the test results view built into Azure Pipelines. Results published in a pipeline appear in the Tests tab of the build or release summary, with test history alongside them. Playwright results reach it as JUnit XML. Playwright's JUnit reporter writes the file, and the `PublishTestResults@2` task reads JUnit format by default. When the task's merge option is set to true, it reports the results from all the result files as a single test run. Once the JUnit files from every shard sit in one job, one publish step with the merge option set to true reports them as one run. For a failed test, the [Tests tab](https://learn.microsoft.com/en-us/azure/devops/pipelines/test/review-continuous-test-results-after-build) shows the error message and stack trace, and an Attachments tab holds the files tied to the failure. Azure DevOps Test Reporting fits teams whose CI already runs on Azure Pipelines. If your pipelines run elsewhere, the Tests tab is no reason to move them. The publish step goes after the Playwright step with a condition that runs it only when every step before it succeeded. Green builds publish their results. The red build, the one you open the Tests tab for, publishes nothing. Run the publish step whether the tests passed or not. Microsoft's Power Platform Playwright sample pipeline does this with `condition: always()` on its `PublishTestResults@2` step. ## Xray ![Xray homepage](/img/posts/best-test-reporting-tools-for-playwright-in-ci-compared/tools/xray-homepage.jpg) [Xray](https://getxray.app/) is a Jira test management app that brings creating, executing and reporting manual and automated tests together in one platform. It tracks automated results in Jira through a REST API that connects with automation frameworks. The Playwright route runs through JUnit. You run Playwright Test with the JUnit reporter to get a JUnit report. Once the report exists, you send it to Xray through its API or one of its integrations. Xray's integrations with CI tools such as Jenkins, Bamboo and GitLab put that upload inside your pipeline. Run the upload from the pipeline, not by hand. Xray also shaped the reporter you use. Xray contributed code to [Playwright's JUnit reporter](https://www.getxray.app/blog/easily-validate-web-applications-using-playwright-testing) so testers can add annotations that Xray uses. Xray fits Jira-centric teams that need manual and automated results traced to their test cases in one platform. A QA lead who reports coverage from Jira gets automated runs next to manual ones there. Pick something else if your team doesn't track its tests in Jira. ## At a glance The table sorts the nine tools by type and route. The Best for column is our call from each entry. | Tool | Type | How Playwright results reach it | Best for | |---|---|---|---| | Currents | Cloud test dashboard | Results collected across machines and workers, assigned to a run by CI build ID | Sharded suites that need one run, per-test history and pull request context | | Allure Report | Test report | Allure Playwright reporter in `playwright.config.ts` | Moving between runs of the same test across reports | | Allure TestOps | Test analytics | `allurectl watch` in CI | Allure users who want flaky detection with no configuration | | BrowserStack Test Reporting & Analytics | Test analytics | `browserstack-node-sdk` in front of the test command | Similar failures in a build run grouped, so you debug the unique causes | | Qase | Test run reporting | `playwright-qase-reporter` | CI results that arrive during the run | | Testomat.io | Test reporting | Reporter in the Playwright config | Playwright traces that open in Trace Viewer | | Katalon TestOps | Test analytics | `@katalon/playwright-reporter` | Playwright results alongside Katalon Studio results | | Azure DevOps Test Reporting | CI built-in test results | JUnit XML through the Publish Test Results task | Teams on Azure Pipelines | | Xray | Jira test management | JUnit XML sent through Xray's API or an integration | Jira traceability for manual and automated tests | ## How to choose If you run a sharded Playwright suite in CI and want one run per build, each test's flake and duration history, pull request context and live results, start with Currents. Currents [collects results across CI machines and workers](https://docs.currents.dev/guides/parallelization-guide/playwright-sharding) and uses the CI build ID to assign them to a run. Its Test Explorer finds flaky, failing or long-running tests and shows each test's duration trend. If that isn't your situation, two questions settle the rest. First, decide who opens the report after a red build. An engineer debugging CI needs the trace, the history and the pull request. A QA lead tracking coverage needs test cases and Jira links. Then decide who owns the plumbing: a report you build in your own CI puts the wiring and the history on you, and a hosted service takes them on in exchange for a vendor in your pipeline. - For a small suite on one machine, Playwright's HTML reporter is enough, plus blob reports if you shard. None of these tools earns its setup yet. - For a report you own, with history, pick Allure Report, whose Tests history lets you move between runs of the same test across reports. - If your team already uses Allure and wants flaky detection it doesn't have to configure, pick Allure TestOps. - If your tests live in Jira, pick Xray, which consolidates the creation, execution and reporting of manual and automated tests in one platform. - If your tests live in a test case manager and your engineers debug from Playwright traces, pick Testomat.io, where an uploaded trace opens in Trace Viewer. - If your tests live in a test case manager and you want results arriving during the run, with the branch, build or commit in the run title, pick Qase. - If you already run on a platform, use its tool. On Azure Pipelines, published test results appear in the Tests tab of the build or release summary. Prepending `browserstack-node-sdk` to your Playwright command sends results to BrowserStack Test Reporting & Analytics. Katalon's `@katalon/playwright-reporter` puts Playwright results in the same Test Runs and reports as Katalon Studio results. ## Frequently asked questions ### What are the best test reporting tools for Playwright? Start with Currents if you run a sharded Playwright suite in CI and want one run per build, each test's flake and duration history, pull request context and live results. For a report you own, with history, pick Allure Report. If your tests live in Jira, pick Xray, and if your team already uses Allure and wants flaky detection it doesn't have to configure, pick Allure TestOps, as [How to choose](#how-to-choose) lays out. ### How do I merge Playwright reports from sharded runs? Merge the blob reports from each shard into one report. A blob report holds every test that ran, its result and its attachments, traces and screenshot diffs included, and blob reports can be merged and converted to any other Playwright report, as [How we picked](#how-we-picked) explains. ### Is the Playwright HTML report enough? For a small suite on one machine, Playwright's HTML reporter is enough, plus blob reports if you shard. None of the tools on the list earns its setup yet in that case, as [How to choose](#how-to-choose) says. ### How do Playwright results get into a test reporting tool? It depends on the tool: Allure Report gets Playwright results through the Allure Playwright reporter, which you add to `playwright.config.ts`, as [Three routes in](#three-routes-in) shows. With BrowserStack Test Reporting & Analytics, you put `browserstack-node-sdk` in front of the command you already use to start a run, and the SDK sends the data automatically. For Azure DevOps Test Reporting, Playwright's JUnit reporter writes the file, and the `PublishTestResults@2` task reads JUnit format by default. ### How do I publish Playwright test results in Azure DevOps? Write JUnit XML with Playwright's JUnit reporter and publish it with the `PublishTestResults@2` task, which reads JUnit format by default. When the task's merge option is set to true, it reports the results from all the result files as a single test run. Run the publish step whether the tests passed or not, as the [Azure DevOps Test Reporting](#azure-devops-test-reporting) section shows with `condition: always()`. ### How does Allure TestOps detect flaky tests? Allure TestOps marks a test flaky when at least 3 status transitions occur within its 10 most recent executions. It detects flaky tests without any configuration, so a test that goes pass, fail, pass, fail inside that window gets flagged, as the [Allure TestOps](#allure-testops) entry explains. ### Does Playwright have Cucumber HTML reports? A maintainer replied in [#36115](https://github.com/microsoft/playwright/issues/36115) that there are no Cucumber HTML reports in Playwright. The reporter said they generate their HTML reports with third-party tools, as [How we picked](#how-we-picked) notes. --- ## About the author **Walter Galvão**, Software Engineer. Walter Galvão is a software engineer at Currents. He writes about Playwright in practice: debugging flaky tests, structuring suites for CI, and the engineering workflows that keep large test suites reliable. LinkedIn: https://www.linkedin.com/in/waltergalvao/