Know what to test
Structured steps, versions, folders, templates, requirements coverage and imports from other tools.
- Steps with expected results
- A version for every edit
- Folders, keys and saved views
New Past results from TestRail and Xray
Know when it's ready to ship.
Test management that turns every result, manual or automated, into a release verdict you can trust. Plan tests, run them, sort failures and see exactly what stands in the way.
- Imports from TestRail and Xray
- Manual and automated in one place
- Built to WCAG 2.1 AA
Works with the tools your team already uses
- Playwright
- JUnit
- GitHub
- Jira
- Slack
- Microsoft Teams
- TestRail
- Xray
- MCP
Product names and logos are trademarks of their owners.
Most tools store your tests. TestPlum answers the question every release asks: is it ready to ship? It weighs every result by what it actually proves, and shows exactly what stands in the way.
How it works
Four jobs. One place for each.
Organised by what you are trying to get done, not by what the tool stores. The advanced parts show up exactly where you need them.
Test it
Suggested selections, keyboard-first execution, live progress, cycles, and Playwright and CI results.
- Suggested selections
- Keyboard-first execution
- Results that cannot be rewritten
Understand failures
Failures grouped by cause and sorted with reasons, one bug per cause, and fixes proven before approval.
- Grouped by cause
- Sorted, with the reasons
- One bug per cause
Decide whether to ship
A ready or not-ready verdict from agreed checks, a trusted pass rate, and verdicts for every project.
- Checks you agree in advance
- A pass counts by what it proves
- Where to resolve each check
The trusted pass rate
A green suite is not proof.
86.7%Pass rate
80%Trusted pass rate
A test that asserts nothing, passes only on retry or changed after it ran proves less than it looks. In the demo project 6 of 39 passes are weak, so they count as 36.0, below the 90% the team agreed.
- A pass that checks something100%
- Manual pass without an expected result70%
- Test changed since it ran60%
- Written by AI, not reviewed yet60%
- Passed only on retry50%
- Flaky test50%
- Automated test with no assertions10%
Everyday
Fast where it counts.
The small things that decide whether people keep a tool open all day.
Record results from the keyboard
Number keys record a result, J and K move between tests, and focus mode hides everything but the test.
Results you can read in greyscale
Every result has a shape as well as a colour, everywhere in the product.
Find anything
Any test, run, bug or requirement, by name or key.
Live runs
Open run pages update as people, runners and CI record results.
Light and dark
Both designed, both accessible, and the sidebar folds into a drawer on phones.
Moving in
Bring your tests. Keep their IDs.
You see what will happen before anything is saved, and a newer export later updates the same tests instead of adding copies.
How migration worksTestRail
XML or CSV export of a test suite
Each test keeps its TestRail ID, so a newer export updates the same tests.
Xray
Xray's JSON, its GraphQL results, the Test Case Importer CSV or Jira's CSV export
Each test keeps its Jira key, so a newer export updates the same tests.
Any CSV
A spreadsheet with one row per step
Rows with an external ID update the matching test instead of adding a copy.
For developers
Automation lands in the same verdict.
Playwright on your own runners, JUnit from any CI, a REST API, and an MCP server so coding assistants can write tests and ask whether a release is ready.
- 01
Runner
Start TestPlum's runner on a laptop, CI box or cloud machine. It checks out a repository, runs its Playwright tests on demand, on a schedule or for each pull request, and reports results with screenshots, videos and traces. Each job gets its own short-lived token.
- 02
Playwright reporter
Records every attempt of every test, including retries, with its evidence, so flaky tests show up for what they are. Tests TestPlum has not seen yet are created with their steps.
- 03
JUnit from any CI
Upload JUnit XML from any pipeline. Uploads are idempotent with a key, and results are matched to tests by automation ID.
- 04
REST API and webhooks
A versioned REST API described in OpenAPI 3.1, with organization API keys, and webhooks signed with HMAC-SHA256 that are retried and logged.
- 05
MCP server for coding assistants
Claude Code, Cursor, VS Code and other MCP clients can read requirements, write and link tests, start runs, sort failures and ask whether a release is ready, within the API key's permissions.
- 06
Git export
Turn manual tests into Playwright test files with one step per test step: download a patch for git apply, or have a runner push a new branch for a pull request. Existing files are never overwritten.
Still in a spreadsheet?
What changes when testing has a home.
| Topic | In a spreadsheet | In TestPlum |
|---|---|---|
| Test history | Cells are overwritten; old versions live in copies of the file. | Every save is a version, and runs keep the version they ran. |
| Results | Typed into a column and replaced on the next run. | Append-only history per test, per run, per step. |
| What to run next | Whatever someone remembers failed last time. | A suggestion: failed or blocked last time, never run, changed, or critical. |
| Automated tests | Pasted in by hand, if at all. | Playwright and JUnit results in the same runs, matched by automation ID. |
| Failures | One row per failing test, sorted by hand. | Grouped by cause and sorted as bug, broken test, environment or flaky. |
| Requirements coverage | A separate sheet someone has to keep in sync. | Worked out from the latest results of linked tests. |
| Release decision | A judgement call in the go or no-go meeting. | A verdict from agreed checks, with each pass weighted by what it proves. |
What is TestPlum?
TestPlum is a test management platform organised around the four jobs of testing: knowing what to test, testing it, understanding failures and deciding whether a release can ship. It keeps manual and automated results in one history and turns them into a release verdict built on evidence.
Who is TestPlum for?
Software teams that test before they release: QA leads who plan testing and decide on releases, testers who run tests and file bugs, developers who automate tests and read failures, engineering managers who need a verdict they can trust, and coding assistants connected through MCP.
Does TestPlum support both manual and automated testing?
Yes. Testers run manual tests step by step, runners you start on your own machines run Playwright tests from your repository, and any CI system can upload JUnit XML. All of it lands in the same runs, failures and verdict.
How does TestPlum decide whether a release is ready?
It checks recorded results against thresholds you agree in advance: runs in scope, completion, pass rate, trusted pass rate, critical tests failing or blocked, open critical bugs and requirements verified. The verdict is ready only when every check passes, and each failing check links to where to resolve it.
Can I move from TestRail or Xray?
Yes. Import a TestRail XML or CSV export, or Xray tests as JSON or CSV, including Jira's CSV export. You see what will happen before anything is saved, and importing a newer export later updates the same tests. Past results from TestRail runs and Xray executions can be imported too, as signed-off runs dated as they happened.
Can I control who sees and edits what?
Yes. Organizations have owner, admin and member roles, and each project has roles built from 14 permissions. A tester role can be limited to only the tests assigned to them.
Is my data isolated from other organizations?
Yes. Every request is scoped to your organization and project, resources from other organizations return 'not found', and automated tests check isolation across read and write endpoints and API keys.
Does TestPlum work with Jira, GitHub, Slack and Teams?
Yes. Send a bug from TestPlum to GitHub or Jira and keep the link, import Xray tests from Jira, post alerts to Slack or Microsoft Teams channels, and connect other tools through signed webhooks and the REST API.
Does TestPlum use AI?
AI is optional. When an administrator switches it on, it drafts tests from a requirement, gives a second opinion on failures and proposes fixes to broken automated tests that must be proven and approved by a person. Everything else works without it.
Is there a dark mode, and is TestPlum accessible?
Yes. TestPlum has light and dark themes, works on phones, where the sidebar opens as a drawer, and is built to WCAG 2.1 AA: keyboard operable, labelled controls, managed focus in dialogs, result statuses that read without colour, and automated accessibility checks in both themes.
Find out whether your next release is ready
Create a workspace, import your tests or write a few, and record a run. Everything on this site is in the product today.