# TestPlum > TestPlum is test management organised around the four jobs of testing: know what to test, test it, understand failures and decide whether to ship, with a release verdict built on evidence. TestPlum is web-based test management software organised around the four jobs of testing. Key facts: - Inside a project there is one place per job: Tests (know what to test), Runs (test it), Failures (understand failures) and Release (decide whether to ship). - Tests have structured steps with an expected result per step, versions, folders and custom fields; requirement coverage is worked out from the latest real results. - New runs start from a suggestion: tests that failed or were blocked last time, never ran, changed since they ran, or are critical. Results are append-only, and signing off a run locks it. - Failures are grouped by cause and sorted as product bug, broken test, environment or flaky, with the reasons; one bug per cause can be sent to GitHub or Jira. - For broken automated tests, a runner reproduces the failure, AI proposes a fix, guardrails refuse changes that would hide a failure, the fix must pass every time, and a person approves it. - The release verdict comes from checks with agreed thresholds; the trusted pass rate counts each pass by how much it proves (no assertions 10%, retry or flaky 50%, changed since it ran or unreviewed AI-written 60%, manual without an expected result 70%). - Playwright tests run on runners you start on your own machines; the Playwright reporter records every attempt; any CI can upload JUnit XML; a REST API (OpenAPI 3.1), signed webhooks, Slack and Microsoft Teams alerts (run signed off, automated failures, verdict changed) and an MCP server for coding assistants are available. - Import from TestRail (XML or CSV) and Xray (JSON or CSV); IDs are kept so re-imports update the same tests. Large imports and exports run in the background with progress and can be cancelled; an import is all-or-nothing. Past results from TestRail runs and Xray executions import as signed-off runs dated as they happened. - Organization and per-project roles (14 permissions), tenant isolation, Argon2id passwords, revocable sessions and an audit log. AI is optional. ## Product - [Overview](https://testplum.com/product/): the four jobs and the portfolio across projects. - [Know what to test](https://testplum.com/product/test-management/): Structured steps, versions, folders, templates, requirements coverage and imports from other tools. - [Test it](https://testplum.com/product/test-runs/): Suggested selections, keyboard-first execution, live progress, cycles, and Playwright and CI results. - [Understand failures](https://testplum.com/product/failure-triage/): Failures grouped by cause and sorted with reasons, one bug per cause, and fixes proven before approval. - [Decide whether to ship](https://testplum.com/product/release-readiness/): A ready or not-ready verdict from agreed checks, a trusted pass rate, and verdicts for every project. ## Moving in and automation - [Migrate](https://testplum.com/migrate/): TestRail, Xray, Any CSV. - [Moving from TestRail](https://testplum.com/migrate/testrail/): how each part of a TestRail export lands in TestPlum, what stays behind, and running both while you switch. - [Moving from Xray](https://testplum.com/migrate/xray/): the four Xray and Jira export formats, how each part lands in TestPlum, and what stays behind. - [Developers](https://testplum.com/developers/): Runner, Playwright reporter, JUnit from any CI, REST API and webhooks, MCP server for coding assistants, Git export. ## Guides - [What is test management?](https://testplum.com/learn/what-is-test-management/): Test management is the practice of planning, writing, executing and reporting on software tests so a team knows what was tested, what passed and whether a release is ready. A test management tool stores test cases, organises them into runs, records every result and links tests to requirements and defects. - [Requirements traceability matrix: what it is and how to build one](https://testplum.com/learn/requirements-traceability-matrix/): A requirements traceability matrix (RTM) is a table that maps every requirement to the test cases that verify it, the latest result of each test and any open defects. It answers two questions before a release: is every requirement tested, and is every tested requirement passing? - [Release readiness: six checks that tell you if a build can ship](https://testplum.com/learn/release-readiness-checklist/): A build is ready to release when explicit, agreed checks all pass: the right test runs are in scope, enough of them are executed, the pass rate meets your bar, no critical tests are failing or blocked, open critical defects are within your limit and enough requirements are verified with none failing. - [Flaky tests: how to detect, measure and fix them](https://testplum.com/learn/flaky-tests/): A flaky test is one that passes and fails on the same code without a relevant change. Measure flakiness from history: count how often a test's outcome flips between pass and fail across its recent decisive results, divide by the number of decisive results minus one, and investigate tests that score above about 0.3. - [Risk-based testing: prioritise the tests that matter most](https://testplum.com/learn/risk-based-testing/): Risk-based testing means running the tests most likely to find important problems first. A practical score adds points for business priority, a recent failure, changes since the last run, never having been run, a failing linked requirement and flakiness; you then run cases from the highest score down until time runs out. ## Compared with spreadsheets - Test history. Spreadsheet: Cells are overwritten; old versions live in copies of the file. TestPlum: Every save is a version, and runs keep the version they ran. - Results. Spreadsheet: Typed into a column and replaced on the next run. TestPlum: Append-only history per test, per run, per step. - What to run next. Spreadsheet: Whatever someone remembers failed last time. TestPlum: A suggestion: failed or blocked last time, never run, changed, or critical. - Automated tests. Spreadsheet: Pasted in by hand, if at all. TestPlum: Playwright and JUnit results in the same runs, matched by automation ID. - Failures. Spreadsheet: One row per failing test, sorted by hand. TestPlum: Grouped by cause and sorted as bug, broken test, environment or flaky. - Requirements coverage. Spreadsheet: A separate sheet someone has to keep in sync. TestPlum: Worked out from the latest results of linked tests. - Release decision. Spreadsheet: A judgement call in the go or no-go meeting. TestPlum: A verdict from agreed checks, with each pass weighted by what it proves. ## Reference - [Security overview](https://testplum.com/security/): controls in place today; no certifications are claimed. - [FAQ](https://testplum.com/faq/): direct answers about the product. - [Glossary](https://testplum.com/glossary/): definitions of software testing terms. - [Full text for language models](https://testplum.com/llms-full.txt) ## Optional - [Create a workspace](https://app.testplum.com/signup)