Automated testing's second act is the hard one. The suite goes red, and someone still has to work out whether that's one problem or forty, whether anyone is already on it, and whether the run will even get started. 1.2 is aimed squarely at that: it turns a wall of red into a short list of real problems, watches the metrics you care about so you hear about trouble before you go looking, and lets a merged pull request start the testing on its own. And when you can't run everything, it now scores every case on how much it deserves a run.

Highlights​

• Failure Patterns — Every automated failure is grouped by what actually went wrong, so a run with two hundred red rows comes down to a handful of problems. AI gives each one a root cause from a catalogue you control, and linking the issue that explains it marks the pattern as a known issue right in the run, so the next person doesn't rediscover it.
• Quarantine — A test failing for a reason you already know about keeps running, but stops counting against your pass rate until it passes consistently again. Your green stays meaningful while the fix is in flight.
• Alerts — Pick a metric, set a threshold, choose who hears about it: a test that keeps failing, a case that has started to flake, a run below your pass bar or stalled, a milestone falling behind. Delivered in the app, by email, in the digest, or to Slack by webhook.
• Risk Scores — Every test case carries a score from 0 to 100 for how much it deserves a run right now, blending failure history, flakiness, staleness, the criticality of the requirements it covers, and its open defects. Sort or filter the repository by it, pick a run's cases by it, weigh it beside Impact Analysis, and click any score to see exactly which signals produced it. Scoring is deterministic and never calls an AI model.
• Automation rules on webhooks — A merged pull request or a new ticket can import the issue, build a run from just the tests that change affects, and send it off for automated execution, with nobody opening TestPlanIt.

Also in 1.2​

• Test case dependencies — Hold a case in a run until its prerequisites pass, then tell the next tester it's their turn.
• Staged test cases — Write cases across several sittings in private, then add them to the repository together.
• ClickUp — Connect ClickUp as fully as Jira: create, link, and sync tasks, custom fields included.
• Notification settings per type — Silence milestone reminders and still hear about review requests and mentions.
• Steps side by side — Put each expected result beside its step instead of beneath it, and see far more of a test case at once.
• Failure rate trend report — Answers one question: is your failure rate getting better or worse? Reports with a date can now be grouped by day, week, month, quarter, or year.
• Counts on every search filter — See how many results each filter option returns before you click, and stop narrowing a search into nothing.
• Audit log retention — Hold audit history to a window you choose instead of letting it grow forever.
• More ways to slice a report — New Result Source, Issue, and Root Cause dimensions, metrics over when cases were created, an Exclude mode on every value filter so "everything except the sandboxes" keeps working as new values appear, and calendar-aligned week and month ranges.
• Revert a review decision — Undo an approval or rejection made in error, within a time limit each project can tighten.
• Restore your own deletes — Deleted a test case, folder, run, session, or milestone by mistake? A new Trash section on your profile lists what you deleted, by name, and restores it along with everything that went with it — no administrator required. Administrators choose how many days that window stays open, or turn it off.
• Several SAML providers at once — Run more than one SAML identity provider side by side, each with its own configuration, its own toggle, and its own button on the sign-in page.
• A default template per project — Each project chooses which template new test cases start from, and you pick it when you create the project.
• Smaller wins — Runs offer to close themselves when the last result lands, clear formatting and a grouped toolbar in the rich-text editor, per-row detail that opens in a row of its own, collapsible panels on test cases, dragging cases whatever the sort, imports that name the fields you missed, milestone completion over the API, and review reminders measured in days instead of hours.

Upgrading​

Back up your database before upgrading. Migrations apply automatically on container start, or with pnpm db:deploy on a source install. See the upgrade notes.

• Two new role permissions. Failure Patterns needs no action: every role that could already add or edit test runs has it. Alerts starts ungranted, so give it to the roles that should create alerts. Administrators always have both. See Roles.
• Failure Patterns starts with your next results. To fold in results you already have, run Analyze existing results once from the project's settings. Root cause suggestions need an AI model connected; grouping and quarantine don't.
• Risk scoring is on by default. Cases are rescored shortly after a run receives results, plus a nightly sweep per project; only changed scores are written, and recomputes stay out of the audit log. Turn it off per project under Project Settings → Risk Scoring — existing scores are kept but stop updating, and the repository's Risk Score filter goes away. The Risk Score column is off until you add it from the column picker.
• Self-service restore is on, with a 30-day window. Every user can restore their own deletes from the Trash section of their profile for 30 days. Change the window, or set it to 0 to turn self-service restore off, from Admin → Trash.
• One API relation was renamed. On the test case model, the relation to a run's cases is now testRunCases rather than testRuns, which matches the TestRunCases records it actually returns. If you query the model API directly — include or select on repositoryCases — update those calls. Nothing changes in the UI, in CSV imports, or for the testRuns relation on issues, milestones, tags, and projects, which are different relations and keep their names.

Thank You​

To everyone who filed an issue, opened a pull request, translated a locale, or told a colleague about TestPlanIt: this release is yours too.

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Every release raises the same three questions. Is it covered? What do we need to retest? Can we prove it? Most teams answer from memory. Memory is what goes quiet in that meeting, and it's what walks out the door when a senior tester leaves. Here's how to answer from records instead: what to produce, when, and for whom.

The Artifacts​

Before the details, the inventory. A release process that can answer all three questions produces five things:

If you produce none of these today, the rest of this post is about where to start. If you produce some, it's about making them trustworthy.

Is It Covered?​

To answer this, you need to know which tests verify each requirement in the release, whether those tests have run, and whether the requirement changed after they did. That's the coverage matrix.

The cost of not having one is quiet. Features ship with a requirement nobody tested, you find out from a customer, and nobody traces it back to the matrix that didn't exist.

A few habits keep it accurate:

• Link tests to individual requirements, not features. A test linked to "Checkout" tells you nothing. A test linked to "Cart totals recalculate when a coupon is removed" tells you exactly what's verified.
• Use the requirements product management already wrote. Don't maintain a second copy. It drifts within a sprint. If those requirements are one-line tickets, link to them anyway. A one-line ticket with a test linked to it beats a detailed spec linked to nothing.
• Look at the gaps first. Requirements with no tests, and requirements whose tests have never run. Those are the ones that will surprise you.
• Re-verify after a requirement changes. When the text changes, every linked test has to run again before it counts. Mark them and don't clear the mark until they do.

Where to start: take this release's requirements, however rough, and put a test id next to each one. The empty rows are your first finding.

What Do We Need to Retest?​

To answer this, you need to know which tests exercise the code that changed in this build, and why each one is on the list. That's the scoped regression list, and the "why" is what makes a team trust it instead of running everything anyway.

The cost of not having it is the full regression pass on every build. It takes days, it delays feedback until the developer has moved on, and it teaches everyone to treat results as noise.

Start from the diff. It describes exactly what changed, and it exists for every build. Turn changed files into tests using three sources, in order of confidence:

1. Tests someone has tied to that code. A tester or developer said "this test covers this module." The most reliable source, and the only one that captures knowledge that isn't in the code.
2. Tests that ran the last time that code changed. Your own history, and it gets better with every release.
3. Tests whose names or steps match the change. The widest net, and the one that catches what nobody thought to tie to the code.

Write the reason next to every test on the list. "Tied to the totals module, and failed the last time it changed" is something a tester can check and act on. Leave out files that change in every build, like changelogs, or every scoped list becomes the full suite.

Then start the run the moment the pull request opens. Put the automated and manual tests in the same run, send the automated ones to the pipeline right away, and leave the manual ones for a tester. The developer gets results while the change is fresh. The tester opens a run that's already half done. Keep full regression for release candidates, where it belongs.

Where to start: tag every test with the module it covers, and ask developers to name the modules a pull request touches. Matching the two by hand is a scoped list. Until it builds itself, write the scope and the reason in the run description.

Can We Prove It?​

To answer this, you need the numbers exactly as they were at sign-off, who approved them, what was known to be broken, and what risk was accepted. That's the execution record, the defect list, and the sign-off record together.

The cost of not having them shows up months later. A live report says 97% at sign-off and 94% today because a flaky suite was re-run. Both numbers are true, and neither is proof, because neither is tied to a moment. Then an escaped bug prompts "why didn't we test that?" and nobody can show that it was a known gap someone accepted.

• Freeze the sign-off report. Capture the numbers at approval, record who and when, and never let that copy change. Keep the live version for day-to-day monitoring.
• Freeze the coverage matrix at each release. Comparing two releases shows which requirements gained coverage, lost it, or shipped with none.
• Record what you didn't test and who accepted it. At release candidate, list open defects with severity, the gaps left open, and the name of the person who said ship anyway. That list protects the team more than any pass rate.
• Don't assemble evidence after the fact. Every execution should already carry a build, a timestamp, a result, and a name. Sign-off is freezing what's there.

Where to start: at your next sign-off, export the report, the matrix, and the open defect list to a dated folder, and write the approver's name on it. That's a sign-off record. Make it automatic later.

The Bottom Line​

Is it covered? A coverage matrix at the requirement level, re-verified when requirements change. What do we retest? A regression list built from the diff with a reason beside every test, started as a run the moment the change lands. Can we prove it? Frozen numbers, a frozen matrix, a list of what was knowingly left open, and the names on the approval.

Five artifacts, each produced at a known moment for a known audience. Start with whichever one your last release was missing when the room went quiet.

That's the thinking behind TestPlanIt 1.1, and it holds whatever tool you use.

Every release raises the same three questions: Is it covered? What do we need to retest? Can we prove it? 1.1 is built to answer them. Requirements management, our most-requested feature, ties every test to what it verifies. Impact analysis narrows a regression run to what actually changed, and automated execution runs that shortlist from the run itself, so a code change gets an answer in minutes instead of a full regression cycle. And a set of smaller additions removes friction your team feels every day.

Know What's Covered — and Prove It​

Requirements management gives your project a single tree of what the system should do, with every test case linked to the requirement it verifies. The tree fills itself from Jira, Azure DevOps, GitLab, Redmine, MantisBT, GitHub, or Gitea, so nobody re-enters what product management already wrote, and results roll up through the hierarchy so "is this feature covered?" is a glance instead of a spreadsheet.

The payoff compounds over a release:

• When a requirement changes, you know which tests to rerun. Suspect flags mark every affected link the moment the content changes, and clear themselves when the test runs again.
• Coverage debt is visible before it bites. The Coverage Gaps report ranks the requirements with no tests, or tests that never ran, and generates test cases straight from a gap.
• Sign-off has evidence. Traceability snapshots freeze the matrix at a point in time, and the Coverage Changes report shows exactly what moved between two of them. Auditors get a record, not a screenshot.

Requirements are opt-in per project. See Requirements to set it up and Coverage & Traceability for reports, snapshots, and suspect flags.

Test What Changed, Not Everything​

A full regression pass on every build is the tax teams pay for not knowing what a change touched. Impact Analysis pays it down: point TestPlanIt at the repository of the application under test, pick two commits or a pull request, and get the Affected Tests right where you compose the run. It works from the git diff alone, with no coverage agent, no build step, and no instrumentation, so it runs against the first application you connect.

Every selection explains itself, with a pin from the test to the code, a keyword match, a prior run that covered the same change, or an AI ranking against the diff, so the team can trust the shortlist and add to it with confidence.

A project can connect several repositories, each with its own cache, Code Pins, and ticket scans. Path patterns decide which files Impact reads, and an Exclude row keeps noisy files out of an analysis, so a changelog or version file that changes in every pull request stops pulling in unrelated test cases. See Test Impact Analysis and the project settings to connect your first repository.

Execute Automation Scripts From Test Runs​

Impact Analysis tells you which tests to run. 1.1 runs them. A test run used to be where automated results ended up; now it is also where they start. Compose the run from the Affected Tests, click Execute automated cases, and the automated portion of the run executes in your CI while testers pick up the manual cases. A single automated case gets Execute automated test for the same thing in miniature.

TestPlanIt starts the job on an execution target the project configured — a GitHub Actions workflow, a GitLab CI pipeline, or a signed webhook for anything else — and hands it two things: the run id, and a URL where the job can fetch the plan of cases to execute. The job runs the matching tests and reports back with the reporter or CLI you already use, pinned to that run. Every result updates its case in the run, so a run that mixes manual and automated cases stays one checklist with one status per case. Testers can still execute any case by hand, and the newest result wins.

Admins can add parameters to a target, like the browsers, operating system, or environment to test against, and whoever executes the run picks from them. Each choice reaches the job as an input, so one workflow covers every combination.

There is no agent to install and nothing framework-specific inside TestPlanIt. The plan lists each case with the identifiers a runner filter can match on; a short script in your repository turns them into a --grep, -k or --tests expression. Two examples ship with the docs.

We chose this shape deliberately. Tools that launch automation from test management usually either install an agent on your machines or send a list of test ids to CI. Agents are a second product to operate. Test-id lists hit CI limits fast — GitHub caps a dispatch at 25 inputs and 65 KB. TestPlanIt sends a pointer instead, and lets the job pull as many cases as the run holds.

See Automated Execution to set up a target and Hybrid Test Runs for how mixed runs behave.

Let the Repository Start the Run​

Impact Analysis and automated execution don't have to wait for someone to click. Add a repository webhook and the repository starts the analysis itself: opening a pull request analyzes it against its target branch, and a push to the base branch analyzes the pushed commits. Each analysis becomes a test run holding the pinned and affected tests, named after the pull request or commit range and linked back to it. A run that came from a merged pull request names that pull request, not just two commit hashes. Set a minimum score on the webhook to take every test the analysis ranks at least that high instead.

Turn on Execute automated cases for the webhook, and each run's automated cases go to your execution target as soon as the run exists. Manual cases wait in the same run for testers. A pull request opens, and the tests it affects are already running. See Repository Webhooks and Executing automated cases.

Never Lose a Test Case Again​

A closed tab, an expired session, or a browser crash no longer costs you the test case you were writing. TestPlanIt keeps your edits as you type and offers them back the next time you open the case, whether you were creating a new one or editing an existing one. Drafts stay private to you and never touch the published case until you click Save. See Auto-Save and Draft Recovery.

One Instance, Every Directory​

Organizations rarely have one identity provider. 1.1 lets Okta manage your employees and Entra manage your contractors on the same TestPlanIt instance, with each directory owning its own users and neither able to overwrite the other. Rotate a SCIM token without a provisioning outage, hold contractors at the right access tier even when a coarse group would grant more, and scope a group to the projects it works on instead of the whole instance. See SCIM Provisioning and Groups.

DeepSeek, First Class​

DeepSeek is now a first-class provider. You could already reach it through the generic OpenAI-compatible endpoint; 1.1 gives it its own integration with model selection, thinking mode, and cost defaults set up for you, so connecting it is one step instead of a workaround. See LLM Integrations.

Link Tickets Without the Busywork​

A ticket key like PROJ-123 is now all it takes to link an issue, whether the request comes from a CSV import, the API, or an AI agent working through the MCP server. Nobody has to open the ticket in TestPlanIt first. Migrating an existing repository with thousands of ticket references becomes a single import. See Linking Issues on Import and the MCP Server documentation.

Map a CSV Once​

Teams that import the same export every week used to re-map the same columns every week. Now you save the column mapping once, with its delimiter, encoding, and row mode, and apply it on the next import. When a file has the same columns as a saved mapping, the wizard suggests it, and one click maps every column. If the file has changed, the wizard tells you which saved columns it couldn't apply.

Share a mapping, and everyone importing with the same template can use it, in every project that uses that template. Saved mappings work in the Test Cases, Shared Steps, and dataset imports. See Saved Column Mappings.

Save Reports, and Freeze the Numbers​

The report you build to answer this week's question is usually the one you need next week too. Save any report, pre-built or custom, under a name and a description, and open it again from Saved Reports at the top of the Reports page. Saved reports are private to you. A live one reopens with every setting restored and runs against current data.

Dates move with it. Pick Last week or This month from the date picker, or the new Last N days, weeks or months, and a live saved report or share link keeps that meaning: open it next Monday and it covers next Monday's last week, worked out in the timezone of whoever saved it, with the viewer stating the dates it is currently reporting. When the dates matter more than the window, choose Fixed dates when you save or share, or pick them on the calendar.

Some numbers must not move. A report shared at release sign-off should show what the team signed off on, not what the data says a month later. Saved reports and share links can now be frozen: TestPlanIt captures the results when you save or share, and every open shows exactly those numbers with when they were captured and by whom, in every access mode, including public and password-protected links. Live stays the default, and share lists show which links are live and which are frozen.

See Saved Reports and Live and Frozen Data.

And More​

• Impact reports. Impact Analysis History and Code Pin Coverage show what each analysis selected and which code your pins cover.
• Report Builder totals. Group rows total their children, and a Show total line option sums the plotted series over time. Every pre-built report now filters from one multi-select Filters menu.
• Everything deleted is in Trash. Administration → Trash lists every kind of soft-deleted record, ready to restore or purge.
• See who can reach a project. A read-only Access page under Project Settings lists every user who can open the project and the role that applies to them.
• Details in a new window. A profile preference opens test cases, review items, and requirements on their own page instead of the docked panel.
• A better MCP server. Rich text comes back as Markdown, so an agent's edit survives the round trip, and results can be recorded per iteration of a data-driven case.
• Easier self-hosting. S3 storage can authenticate through the AWS default credential chain (an instance role or IRSA, no keys in your config), and WORKER_MAX_MEMORY_RESTART and WORKER_MAX_OLD_SPACE_MB raise worker memory limits on busy installs.

Upgrading​

Back up your database before upgrading. Migrations apply automatically on container start, or with pnpm db:deploy on a source install. See the upgrade notes.

• Bundled file storage moves from MinIO to RustFS. MinIO no longer publishes Docker images, so the storage bundled with Docker Compose and the Helm chart now runs RustFS, an open-source S3-compatible server. A migration script copies your files across and leaves the old directory untouched as a backup. Follow Migrating from MinIO when you upgrade. Installs that use AWS S3 or their own S3 service are not affected.
• Project Settings permission now makes a project admin. A role with Add/Edit on Project Settings makes its holders project admins of every project where it applies, and the role name "Project Admin" no longer carries special meaning. Review your custom roles before upgrading. See Project admins.
• Reindex search. Once the new version is running, run a reindex from Administration → Search Engine so requirement data on existing issues is indexed and searchable.

Thank You​

To everyone who filed an issue, opened a pull request, translated a locale, or told a colleague about TestPlanIt: this release is yours too.

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Ten months after opening the source, more than forty releases into the 0.x line, and eighteen beta pre-releases later, the version number has caught up with the product: 1.0 completes the feature set we imagined when we started — the platform we always intended TestPlanIt to be.

The Road to 1.0​

TestPlanIt went open source in November 2025. Since then the 0.x line grew from a test case repository into a full test management platform: manual and automated execution, exploratory sessions, parameterized test cases, review and approval workflows, webhooks, an MCP server, SCIM provisioning, data lake export, and AI features that run on your own LLM.

At the end of June we opened a beta channel and spent the summer finishing the job. Eighteen pre-releases went out to self-hosters who built from source, filed issues, and told us what broke. That feedback loop is the reason 1.0 ships with confidence — thank you to everyone who ran a beta.

What 1.0 Means​

The 0.x releases were always production-ready — teams have been running TestPlanIt as their system of record for months. What 1.0 marks is completeness: the feature set we originally imagined for the platform is now all here. Along with it:

• Semantic versioning. From here on, breaking changes mean a major version, and upgrades within 1.x are routine.
• Prebuilt images are back. The beta channel was source-only; with 1.0, the official Docker images pick the release up again. docker pull gets you the full 1.0 feature set.
• A supported upgrade path. Whether you're coming from the 0.44.3 main line or riding the beta channel, v1.0.0 is the same code graduating to main.

What's New Since 0.44.3​

If you stayed on the main line, 1.0 is the biggest set of improvements TestPlanIt has ever shipped at once — 702 commits since v0.44.3. Here's the complete list.

Jira integration, end to end​

• Milestone sync — milestones sync straight from Jira: issue membership, webhooks, and live updates, with milestone imports filterable by Release or Sprint.
• A release cockpit — the milestone page adds burndown with a variance heat strip, a release-readiness "% ready" rollup, a per-case traceability matrix in the PDF export, and an activity log. In-scope issues roll up test cases and results from every linked project.
• AI in the Jira panel — generate test cases and QuickScript automation scripts from the TestPlanIt panel on an issue, without leaving Jira. The panel shows each case's fields per template, with Steps as a count chip that opens a step-list popover — and you can quick-generate cases right from a milestone's scope table.
• Self-refreshing OAuth — expired tokens refresh themselves during background syncs; you're only notified when re-authorization is genuinely needed.

AI generation that can see your app​

• Images as context — pull screenshots from linked Jira issues or Azure DevOps work items, use rich-text documents with embedded images, or let TestPlanIt crawl a URL and capture page screenshots. The AI reads them alongside the text and writes cases that match what's actually on screen.
• Any provider — a multimodal pipeline translates images per provider, so it works with whichever LLM you've connected.
• Cost visibility — a cross-project LLM Usage report shows admins where AI spend goes, and model cost fields auto-fill from provider pricing.
• QuickScript anywhere — generate automation scripts from an API token, the MCP server, or the Jira panel.

Automated runs, analyzed​

• Execution metrics — per-run metrics and duration, an execution timeline that visualizes real parallelization across workers, within-run flaky detection that understands retry semantics, and result filters to slice big runs.
• Live and hands-off — an Automation Runs card streams live progress, abandoned runs close themselves, explicitly linked cases flip to automated when results arrive, and completed runs can be duplicated straight from the runs list.
• Counted correctly — milestone completion, burndown, member coverage, traceability exports, and project-health metrics resolve automated case status through a single effective-status source, so automated work never reads as "not run".
• Agent-readable — AI agents get it all through the MCP server: automated results, run-case editing, a review-inbox tool, and repository reporting rollups.

Across the app​

• A revamped repository — a dockable, drag-resizable case-details panel; a latest-result column you can sort by; reorderable, resizable columns with remembered order, width, and sort.
• Filter across every dimension — combine multiple filters in one bar with shareable URLs, search inside advanced-filter comboboxes, and save views you return to often.
• Review workflows — request approvals in bulk, work a dedicated review inbox with full case details and decision badges, and track requested reviews in a pending queue with reminders. Approving applies the workflow transition automatically, and reviews cancel themselves when their subject is deleted or moved.
• Full result history — a case's complete history, virtualized to stay fast at any size, with the current run highlighted.
• Composition lock — freeze a run's set of test cases the moment execution starts; manual or auto-lock per project.
• Even test distribution — spread a run's case assignments across the team in one step.
• Ready-to-complete notifications — the right people are notified the moment a run's last result lands, and run and session start/end dates derive from actual results.
• Issue list filters — multi-select status, priority, and issue-type filters.
• Infinite-scroll management tables — issues, users, groups, roles, projects, tags, audit logs, and webhook deliveries load on scroll.
• Document previews — Word, Excel, and PowerPoint render inline, with full-height PDF preview and keyboard navigation.
• Link previews — TestPlanIt links pasted into Slack, Teams, or iMessage unfurl into a card that says what they point to; record details stay private unless the instance opts in.
• Sharper duplicate detection — the compare view highlights the fields that differ with word-level text diffs, and shared-step candidates filter by minimum cases and steps.
• Human-readable record keys — optional project-prefixed identifiers, e.g. PROJ-123.
• Accessible Dark theme — meets WCAG AA, enforced by a CI contrast gate.
• 17 languages — including full right-to-left support for Arabic and community-contributed Czech.
• Milestone Readiness report — plots release readiness over time, with automation trends that hold up at scale.
• Findable folders — search the folder tree directly; every folder picker is searchable and virtualized for large trees.
• Your work, front and center — pending reviews sit atop Your Assignments, and profiles gain a role-scoped Assignments section plus a My Comments view with scope filters, search, and infinite scroll.
• A user directory with boundaries — collaborators see only the people who share a project with them.
• Guided first sign-in — new users land on a "Get started" prompt into the create-project wizard.

Platform & performance​

• A rebuilt data and access layer — the 1.0 foundation: access control enforced at the query layer, two-phase pagination that took the heaviest lists from ~22s to ~270ms, and project access resolved once per request instead of re-asked per query.
• Opt-in read-replica routing — Postgres read/write splitting, entirely in-app.
• Official images and a Helm chart — self-host from prebuilt images with a single-tenant Helm chart; no building from source.
• Faster lists everywhere — runs, users, and audit logs window, prefetch, and stream on scroll, and Trash is redesigned as master-detail with virtualized scrolling.
• Operator knobs — configurable API rate limits, a configurable upload ceiling via UPLOAD_MAX_MB, event-loop lag on /api/health, nginx request timing with local overrides and custom error pages, and capped container logs.
• AI Tools admin section — grouped settings with real provider Test Connection errors.

Reliability & polish​

• Steadier live updates — no reconnect refetch storms; connections defer until the browser is idle.
• A trustworthy audit trail — correct actor attribution (API tokens included), rich-text edits captured, readable diffs, richer filtering, and integration credentials encrypted on every write path.
• Search that never drifts — indexing moved to post-commit sync so results always match the database, deletes remove their documents, and search result cards are real links.
• Webhooks fan out — Issue events reach every linked project, and deliveries show which record each one was about.
• Edit cases mid-run — fix a test case in place from the run panel, without leaving execution.
• Embedded media, everywhere — images and videos embedded in descriptions resolve and render wherever they appear.
• A long tail of polish — a modernized header, natural case-insensitive name sorting, no more theme flash, chart metrics correct in every locale, digest emails that skip what you've already read, integration calls that honor Retry-After, and an OpenAPI spec regenerated from the schema with a parity test so it can't drift again.

Upgrading​

Back up your database before upgrading. 1.0 moves schema changes to versioned migrations, and a database created by a 0.x release needs a one-time baseline step before its first v1.0 start — see the upgrade notes for the exact commands.

git pull origin main
pnpm install
pnpm generate
pnpm db:deploy
pnpm build

For Docker deployments:

docker pull ghcr.io/testplanit/testplanit-selfhost:latest

Self-hosted deployments use the testplanit-selfhost image — domain-agnostic, so one image serves any hostname, and published for both linux/amd64 and linux/arm64.

If you've been on the beta channel, v1.0.0 is the graduation of that line — upgrade as usual.

What's Next​

1.0 is a milestone, not a finish line. Work is already underway on requirements management — linking requirements to test cases and results for end-to-end traceability, our most-requested feature — with more to come driven by your feedback.

Thank You​

To everyone who filed an issue, opened a pull request, translated a locale, ran a beta build, or told a colleague about TestPlanIt: this release is yours too.

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Here's to 1.0 — and to everything your team ships with it.

TestPlanIt now fills in those steps for you. When an automated result creates or matches a case, the case's Steps (each an action and its expected result) are derived from the automation that produced it — so your automated cases read like real, reviewable test cases instead of opaque green/red rows.

Steps, derived from the automation itself​

Plenty of automated tests already describe their own structure — you just have to read it the right way. TestPlanIt does, deterministically (no AI, no guessing, identical every time):

• Cucumber / Gherkin — each Given and When line becomes a step, and a Then becomes the expected result of the step before it, so the assertion lands right next to the action it verifies.
• Playwright — each test.step() title becomes a step, and a nested assertion becomes its expected result.

Because a single shared mapping powers this, a test produces the same Steps whether you import its results or report them live from a run with the WebdriverIO or Playwright reporters. Your automated suite stops being a black box and becomes documentation that's always in sync with the code.

And the tests that have no steps? Your AI writes them​

Here's where it gets really interesting.

Frameworks like Mocha and Jasmine have no native step structure — to a test management system, a test surfaces as just a name and a pass/fail. So in other tools, those cases stay empty forever.

TestPlanIt does something different. It feeds your own LLM the actual sequence of commands each test executed — every navigation, element lookup, click, keystroke, and assertion — and turns that command stream into readable, user-facing steps that describe what the test actually did, not a guess from its title. Those commands reach it two ways: the WebdriverIO reporter captures them live during the run, and many imported result files already embed them — a WebdriverIO junit report, for example, records every command in its output, and TestPlanIt reads it the same way. Only when a result carries no commands at all does it fall back to inferring the steps from the test's descriptive name.

• It's your AI, your data. Derivation uses the LLM integration you've already set up for the project — bring-your-own OpenAI, Anthropic, Gemini, Azure, or a self-hosted model. Configuring a provider is the opt-in; if you haven't, the feature is completely inert.
• It runs in the background. Suites and imports run at the scale of thousands of cases, so derivation is never done inline — it's queued as a background job and never slows your CI run or your import down.
• A human stays in the loop. When the steps are ready, whoever ran the suite or import gets an "AI-Derived Test Steps Ready" notification linking straight to the run, so they can review the steps for accuracy. They're a strong starting point, not gospel — and you can tune the prompt that generates them.

So a Mocha suite that used to land as a wall of bare names now becomes test cases that actually describe the flow they exercise — derived from the commands they ran, by the model you trust, on infrastructure you control.

Safe by default — it never overwrites your work​

Derivation only ever touches a case that has no steps. The moment a case has steps — whether you wrote them, edited them, or they were derived earlier — that case is the source of truth and is left alone. Re-import all you like; your edits are never clobbered.

When you do want a clean re-sync, both the importer and the reporters expose an opt-in, deliberately destructive overwriteSteps switch (off by default) that replaces a case's steps every run — including via the AI path.

Turning it on​

• Deterministic steps (Cucumber, Playwright, WebdriverIO) work out of the box — no setting to flip.
• AI-derived steps for low-structure tests just need an LLM provider assigned to the project. Both entry points support it: the Automated Test Results Import and the WebdriverIO reporter (for Mocha/Jasmine runs, with captureSteps on).

Full details are in Test Step Derivation.

Why it matters​

Test management tools have spent years treating manual and automated testing as two separate worlds — rich, documented cases on one side, anonymous pass/fail counters on the other. This collapses that gap. Your automated results become first-class test cases: readable, reviewable, traceable, and useful to the next person who has to understand what coverage you actually have — without anyone retyping a single step.

That's the kind of living documentation teams keep meaning to write and never do. Now it writes itself.

Your team plans and triages in Jira. Now AI test case generation happens there too. The TestPlanIt for Jira app's issue panel has a new Generate Test Cases button: open a ticket, generate a suite of test cases from it, review them as they stream in, and save them straight into TestPlanIt — linked back to the issue — without a single context switch.

Wherever your team works​

Not everyone lives in the same tool. Testers and QA leads often spend their day in their test management system; developers, product owners, and the people triaging the backlog spend theirs in Jira. Turning a ticket into test coverage shouldn't depend on which window you happen to have open.

You could already generate test cases from an issue inside TestPlanIt. Now you can do it from the Jira issue panel too — same generator, same results. Whichever tool you're already in, you stay there.

The full engine, in the panel​

This isn't a stripped-down sidecar. The panel runs the same generation pipeline as the in-app wizard:

• Your LLM, your data. Generation uses the LLM integration you've configured for the project — bring-your-own OpenAI, Anthropic, Gemini, Azure, or a self-hosted model. Nothing is sent to a third-party AI we picked for you.
• The same rich context. It feeds the AI the issue's title, description, and comments, the linked Jira issues (one hop — Epics, blockers, related tickets) with their own bodies and comments, and the existing test cases in the destination folder so it complements your coverage instead of duplicating it.
• Real permissions, real attribution. The panel maps your Jira account to your TestPlanIt user and enforces your project access. Generated cases are authored by you, not a faceless service account. If your account isn't linked or lacks access, the button simply doesn't appear.
• Live streaming. Cases appear as they're generated, so you can start reviewing immediately instead of staring at a spinner.

Why this is different​

Plenty of tools can ask an AI to write test cases. The differentiator is what happens next. Here the output isn't a throwaway block of text you copy somewhere — each case is a first-class test case in your repository: versioned, templated, taggable, linked to the originating ticket, and ready to drop into a test run. The generation happens where the work already is, and the result lands where your test coverage already lives.

That round trip — ticket to reviewed, linked, runnable test cases — happens without ever leaving the issue.

Try it​

Install the TestPlanIt for Jira app and start turning tickets into test coverage straight from the issue panel.

Read the full documentation →

That's the picture with SCIM 2.0. SAML put your IdP in charge of who can sign in to TestPlanIt; SCIM puts your IdP in charge of who exists at all.

Where SAML Left Off​

SAML has been in TestPlanIt for a while now, and if you've got it wired up to Okta, Entra, or any other IdP, sign-in is already a solved problem. New hires use their corporate account. Departures lose access the moment their IdP account is disabled.

SAML answers who can sign in. It doesn't answer who exists, who they're grouped with, and whether they're active right now.

The first time a user signs in via SAML, TestPlanIt creates an account for them — that's auto-provisioning. From that point on, the row is TestPlanIt's. Their group memberships are something an admin picked in TestPlanIt. Their role is something an admin picked in TestPlanIt. When someone changes teams or gets promoted, somebody opens Admin → Users and clicks. When someone leaves, the IdP closes the sign-in door, but the TestPlanIt row stays active and visible until an admin flips it inactive or deletes it. Audit history isn't at risk either way — TestPlanIt has always soft-deleted users so attribution survives — but somebody had to remember to do the tidy-up.

SCIM closes the gap. Where SAML gives the IdP the keys to the front door, SCIM gives it the keys to the user list. New hires get added. Group changes flow through. Departures get marked inactive automatically. The row still sticks around for audit purposes; it just stops showing up in active-user pickers without anyone clicking.

What That Buys You​

Your identity provider — Okta, Microsoft Entra, OneLogin, anything that speaks SCIM 2.0 — keeps TestPlanIt's user list in sync the same way it keeps every other enterprise tool's user list in sync. New hires show up in TestPlanIt automatically the instant they're added to the right IdP group, with the right groups already attached. Departures flip to inactive the moment HR closes the loop in the IdP. Reorgs that move someone from QA to Engineering shift their TestPlanIt group membership without anyone touching TestPlanIt.

You stop maintaining TestPlanIt's user list and start letting the IdP do its job — same way you already do for the other twenty SaaS tools in your stack.

What Changes for Admins​

A lot less work. A few specific things to know:

You won't accidentally rename a SCIM-managed user. The Users and Groups admin pages add a small SCIM badge to anyone provisioned through the IdP, and the edit / delete / password actions go quiet for those rows. The IdP is the source of truth — if you need to change a SCIM user, change them where they came from. The lockdown isn't there to restrict you; it's there to prevent the kind of two-system disagreement that takes hours to debug because everything looks correct in isolation.

Your auditors get a clean answer. "How do you provision and deprovision users?" — "SCIM 2.0, here's the audit log filtered to the SCIM source, here's the originating token, here's every change with a timestamp." Done.

Bulk sync won't blow up your Slack channel. The first time your IdP runs a full push — 2,000 new users on Monday morning — the outbound webhook system folds the flood into summary events instead of 2,000 individual Slack pings. Routine day-to-day syncs stay 1:1.

Setup is one page. Mint a token at Admin → Authentication → SCIM Provisioning, paste it into your IdP, click Test SCIM. If the test reports green, your IdP is going to work. If it reports red, you find out now instead of when payroll's 6 AM new-hire push runs and you have to explain why three people don't have access on their first day.

What Doesn't Change​

The good stuff. TestPlanIt is still TestPlanIt — the test cases, the runs, the sessions, the integrations, the reports, your data. SCIM only takes over the identity layer. Local accounts still work for the cases where they should (your demo logins, your admin-of-last-resort, your "we don't have an IdP" deployments). Self-registration, Magic Link, SSO — none of it goes away. SCIM is opt-in, layered on top.

Who This Is For​

If you're at a 50-person company already signing in via Okta SAML, SCIM is the obvious next step. The day you connect it, your onboarding checklist gets a line shorter, your offboarding cleanup goes from "check TestPlanIt for stale accounts" to "nothing to check," and group memberships stop being a thing somebody has to remember to set.

If you're at a 500-person company, the manual user management was already untenable. SCIM is the version of TestPlanIt you can stand behind in a security review.

If you're at a 5-person company, you probably don't need SCIM yet. We're still glad to have you. The local sign-up flow is right where you left it.

How to Get It​

1. Update to TestPlanIt v0.24.0.
2. Open Admin → Authentication → SCIM Provisioning and mint a token.
3. Drop the token into your IdP's SCIM connector — Okta, Entra, and OneLogin all work out of the box, and any other spec-compliant client will too.
4. (Optional) Subscribe a Slack channel or a custom HMAC endpoint to the SCIM lifecycle events at Admin → Tools & Integrations → System Webhooks so provisioning activity mirrors into your existing ops channels. Same machinery as the project-level webhooks, just scoped to system events.

Full setup walkthroughs for the three IdPs we tested most heavily live at SCIM Provisioning in the docs.

We're excited to announce @testplanit/playwright-reporter, an official Playwright reporter that automatically sends your test results to TestPlanIt in real-time.

Why a Playwright Reporter?​

Playwright is one of the fastest-growing browser automation frameworks, and it's the engine behind countless teams' E2E suites. Until now, getting Playwright results into TestPlanIt meant exporting JUnit XML and importing it via the CLI. That works, but it adds steps and loses context.

The new reporter pushes results directly to TestPlanIt as your tests run — and because Playwright runs reporters in a single main process, there's nothing extra to wire up. One reporter sees every worker, project, and spec, and reports them all to a single test run. No launcher service, no worker-coordination flags.

Key Features​

Real-Time Reporting​

Results are sent to TestPlanIt as each test completes. You can watch your test run populate live.

Link Tests to Test Cases — Without Renaming Anything​

Established suites shouldn't have to rename every test to [1234] …. Use a Playwright annotation to attach the case ID as metadata and keep your titles clean:

import { test, expect } from '@playwright/test';

test('should login with valid credentials', {
  annotation: { type: 'testplanit', description: '1234' },
}, async ({ page }) => {
  // Links to TestPlanIt case #1234 — no case ID in the title
  await page.goto('/login');
  // ...
});

Prefer tags or titles? Those work too — a @C1234 tag or a [1234] in the title are both matched by the configurable caseIdPattern. Mix and match; the reporter de-duplicates.

Auto-Create Test Cases​

Don't want to create test cases manually first? Enable autoCreateTestCases and the reporter will create them for you:

['@testplanit/playwright-reporter', {
  domain: 'https://testplanit.example.com',
  apiToken: process.env.TESTPLANIT_API_TOKEN,
  projectId: 1,
  autoCreateTestCases: true,
  parentFolderId: 'Automated Tests',
  templateId: 'Default Template',
}]

On first run, test cases are created automatically. On subsequent runs, results link to the existing cases.

Attachment Uploads​

Playwright already captures rich evidence — screenshots, videos, and traces. The reporter uploads all of it to the matching result, including anything you add with testInfo.attach():

// playwright.config.ts
use: {
  screenshot: 'only-on-failure',
  video: 'retain-on-failure',
  trace: 'on-first-retry',
},

Want to keep uploads lean? Filter with attachmentTypes: ['image/'] to upload screenshots only.

Folder Hierarchy from Describe Blocks​

With createFolderHierarchy, your nested test.describe blocks become folders in TestPlanIt:

test.describe('Authentication', () => {
  test.describe('Login', () => {
    test('should login successfully', async ({ page }) => {
      // Creates: Authentication > Login > "should login successfully"
    });
  });
});

Full Retry History​

Playwright reports each retry attempt, and so does the reporter — a flaky test that fails then passes records both results against the same case, so you keep the full attempt history.

Quick Start​

Install the package:

npm install --save-dev @testplanit/playwright-reporter

Add it to your Playwright config alongside your existing reporters:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['list'],
    ['@testplanit/playwright-reporter', {
      domain: 'https://your-instance.testplanit.com',
      apiToken: process.env.TESTPLANIT_API_TOKEN,
      projectId: 1,
    }],
  ],
});

Run your tests:

npx playwright test

After completion, you'll see a summary:

[TestPlanIt] Results Summary
[TestPlanIt] ═══════════════════════════════════════════════════════════
[TestPlanIt]   Test Run ID: 123
[TestPlanIt]   Duration: 45.2s
[TestPlanIt]
[TestPlanIt]   Test Results:
[TestPlanIt]     ✓ Passed:  15
[TestPlanIt]     ✗ Failed:  2
[TestPlanIt]     ○ Skipped: 1
[TestPlanIt]
[TestPlanIt]   View results: https://your-instance.testplanit.com/projects/runs/1/123
[TestPlanIt] ═══════════════════════════════════════════════════════════

CI/CD Ready​

The reporter works seamlessly in CI/CD pipelines:

GitHub Actions:

- name: Run E2E tests
  env:
    TESTPLANIT_API_TOKEN: ${{ secrets.TESTPLANIT_API_TOKEN }}
  run: npx playwright test

Include build information in your run names:

runName: `Build #${process.env.GITHUB_RUN_NUMBER} - {browser} - {date}`,

Documentation​

For complete configuration options, examples, and advanced features like custom case ID patterns, attachment filtering, and milestone/configuration associations, see the Playwright Reporter documentation.

Get Started​

The @testplanit/playwright-reporter package is available on npm:

npm install --save-dev @testplanit/playwright-reporter

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Happy testing!

TestPlanIt now ships Automation Candidates — an AI-ranked report that tells you which manual cases to automate next, with a one-sentence rationale for every case explaining why it landed where it did. Pick a strategy, click Run.

Pick the Strategy, Not the Cases​

What "next to automate" means depends on what your team is optimizing for this quarter, so you pick:

• Most Executed (highest ROI) — default. The most-run cases; every future regression that touches them recovers tester time.
• Flakiest First — Cases whose outcomes flip the most. A deterministic oracle replaces a flaky manual judgment and stops eating time on every retry.
• Longest to Execute — Highest manual-execution forecast. Automating a 45-minute case recovers far more than a 5-minute one.
• Oldest First — Long-lived, settled cases. Safer to automate without rework.
• Newest First — Recently authored cases, before new coverage accumulates.
• Random Sample — An unbiased control to sanity-check the others.

The strategy isn't just a filter — it's the primary signal the ranker uses. Switching strategies regenerates the report and gives a genuinely different recommendation.

The AI Reads More Than the Number​

With an LLM integration configured, the report sends each eligible case's full context — name, custom field values resolved to human-readable names, step count, execution count, flakiness, manual-execution forecast, and any drilled-down metadata from issues linked in Jira, GitHub, Azure DevOps, GitLab, or Gitea/Forgejo.

The model doesn't just sort by your chosen metric — it reads each case and weighs the metric against business signals. A case tagged critical-area and linked to a high-severity issue ranks differently than one with the same execution count and no such context. Each gets a one-sentence rationale, which is what makes the report hand-to-a-planning-meeting actionable rather than a list you still have to interpret.

Works Even Without an LLM​

Plenty of teams want this report before a project-level LLM is configured. So Automation Candidates ships with a heuristic fallback: it ranks deterministically by the selected strategy's metric, scores each case 0–100 against the eligible-set maximum, and labels the snapshot with a Heuristic badge so viewers know the reasoning is metric-only. The summary points to Admin → AI Models for the richer LLM reasoning when you're ready.

Heuristic rationales are localized to the generator's preferred language, matching how the LLM path responds in the prompt's language — a French QA lead sees French rationales, a Japanese tester sees Japanese.

Shared Snapshots, Not Live Views​

This report benefits from being a snapshot. When your manager opens it Monday, they should see the ranking the QA lead shared Friday — even if execution data has shifted or five candidates have since been automated.

Every generation produces a snapshot; regenerating appends a new one to the history rather than replacing it. The history dropdown labels each with its strategy — "Automation Candidates ranked by Most Executed (highest ROI) — Jun 1, 2026 5:38 PM" — so you can compare lenses and pick the one that fits the conversation.

Where to Find It​

Open any project, go to Reports, and pick Automation Candidates from the top of the report type dropdown. Set your strategy, pick how many cases to rank, and click Run Report. First-time generation with a thinking-capable model and 100 cases can take a couple of minutes; smaller sets and lighter models are much faster, and the heuristic fallback finishes in seconds. Full reference in the Automation Candidates guide.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

We just made that job a one-liner.

Three new endpoints, one wire format​

TestPlanIt now ships three GET endpoints designed for analytics ingestion:

• /api/export/test-run-results — the execution fact table (one row per recorded result)
• /api/export/repository-cases — the test-case dimension table
• /api/export/audit-log — the compliance feed (one row per audited mutation)

Each one streams NDJSON (newline-delimited JSON) over HTTP chunked transfer encoding. That's the wire format Spark, Snowflake COPY INTO, BigQuery bq load, Databricks Auto Loader, Airbyte, Fivetran, Logstash, and Vector all natively understand. No client library, no intermediate parsing, no need to materialize the whole response — your pipeline consumes one record at a time, all the way through.

What it looks like​

Pull every result executed since the last sync:

curl -H "Authorization: Bearer $TOKEN" \
  "https://testplanit.example.com/api/export/test-run-results?since=2026-05-01T00:00:00Z&pageSize=1000"

The response opens with a manifest line, streams rows, and closes with an end-trailer:

{"type":"manifest","schemaVersion":1,"resource":"test-run-results","exportedAt":"...","since":"2026-05-01T00:00:00.000Z","pageSize":1000,"projectId":null}
{"id":12345,"testRunId":42,"testCaseId":200,"statusName":"Passed","isPass":true,"executedAt":"2026-05-30T10:00:00.000Z",...}
{"id":12346,"testRunId":42,"testCaseId":201,"statusName":"Failed","isPass":false,"executedAt":"2026-05-30T10:00:01.000Z",...}
...
{"type":"end","count":1000,"cursor":"eyJrIjoi..."}

The trailer carries a base64url cursor. Hit the same endpoint with ?cursor=<value> to get the next page. The cursor is null when you've exhausted the dataset — that's the signal to stop.

Stable forward iteration​

The cursor encodes the (executedAt, id) tuple of the last row. The next page's WHERE clause is strict-forward with a tiebreaker:

WHERE (executedAt > c.executedAt)
   OR (executedAt = c.executedAt AND id > c.id)

That's a deliberate choice. Naïve WHERE executedAt > c.executedAt skips rows with identical timestamps; WHERE executedAt >= c.executedAt duplicates the boundary row. The composite tuple is the only way to walk the table without either. Combined with the indexed sort key, page fetches stay fast at millions of rows.

Real-time too: the webhook event catalog​

For workloads that need push, not pull, TestPlanIt's outbound webhooks fire on every meaningful state change. We now also publish the catalog of triggers — case.created, test_run.completed, iteration.result.recorded, issue.updated, the whole list — at /api/webhooks/events:

curl -H "Authorization: Bearer $TOKEN" \
  "https://testplanit.example.com/api/webhooks/events?category=test-run"

Drive your downstream subscription config from this catalog. No more reading source to figure out what events exist.

The architecture pick​

We deliberately stopped short of shipping a native Kafka/Kinesis/Pub-Sub producer. The reason: almost everyone already has a webhook → event-bus bridge they trust — Kafka Connect REST source, AWS API Gateway → Kinesis Firehose, Google Pub/Sub HTTP push, even a 20-line Vector pipeline. Adding three SDK adapters to TestPlanIt would mean three runbooks, three sets of CVEs, three "why isn't it delivering" failure modes — for ergonomics most of our customers don't need.

What customers DO need is the format their data lake speaks and the schema of every event. That's what these endpoints give you.

Try it​

The endpoints ship in the next release. To preview today, pull main and follow the Data Lake Export docs page for end-to-end recipes — curl, Python, Spark, Snowflake COPY INTO, and Databricks Auto Loader are all covered.

Feedback or a request for a built-in Kafka adapter? We're listening — open a discussion on GitHub and tell us what you'd want.

This release gives that claim a backbone: required result fields that must be filled in, a configurable window for editing a recorded result, and an optional explanation when a completed outcome is flipped — with every edit captured in full, before-and-after detail.

Required Fields, Enforced When You Save​

If a template has a result field marked Required, results can't be saved without it — checked on the server, so it holds for the Add Result form, the API, and connected agents alike.

The quick Pass & Next and per-iteration buttons can't capture custom fields, so for a case with a required field they open the full Add Result dialog (pre-set to your chosen status) for you to fill it in and save. See Required Result Fields.

An Edit Window You Control​

The system-wide edit window for results now has a dedicated control on the Statuses page — no restriction, disable in-place editing everywhere, or allow editing up to a maximum number of minutes. And each project can tighten it in its Advanced settings (a shorter window, or none at all), never loosening it past the system ceiling.

Once the window closes, a correction is recorded as a new attempt rather than overwriting the original, so both stay on the record. System administrators can always edit, and every edit lands in the audit log with before-and-after values. See the Result Editing Policy and Advanced settings.

Flips That Explain Themselves​

Turn on Require justification on result flip and changing one completed outcome to a different one — Passed to Failed — prompts for Result Details before it saves. It fires only on a genuine flip; a first result, or any move involving a non-completed status like Untested or In Progress, is never blocked. The note is required, but the flip is never prevented. Automated imports (CLI and CI) aren't affected.

Everything On the Record​

The audit log records every result edit with the exact fields that changed and their old and new values — sensitive values masked — whether the edit came from a tester inside the window or an admin afterward. More in the Audit Logs guide.

What Your Testers Will Notice​

Most of this stays invisible until an administrator turns it on, but flag these to your team:

• Pass & Next may open the Add Result dialog — when the case has a required result field. That's expected, not a bug.
• The notes box is now labeled "Result Details" everywhere. Same box, one name.
• A submission can ask for more — Result Details on a flip, or a new attempt once the edit window has closed.

Safe to Turn On​

Everything here is opt-in. Flip justification is off until a project enables it, the edit window defaults to "projects decide," and required-field enforcement does nothing unless a field is actually marked required. Roll it out to one project, then widen.

Upgrade​

Pull the latest, install, generate, and build. Docker users can pull the latest image. Full upgrade notes are in the release notes.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

Every QA team has the same rule, and every QA team breaks it. "Don't mark a case Active until the lead has looked at it." "Don't complete the sprint test run until the PM signs off." "Don't approve the session report unless someone double-checked the evidence."

The rule is in the wiki. It's in the new-hire onboarding. It's in someone's Slack DM history from last quarter. And every release cycle, somebody clicks the wrong button and a half-finished case ships as "Active," or a not-quite-done test run gets stamped "Complete" thirty seconds before the audit meeting starts.

It's not a tooling problem you can fix with another Confluence page. It's a tooling problem you fix by putting the gate inside the tool.

TestPlanIt v0.30.0 ships Review & Approval. Any workflow state can be marked as requires review. After that, transitioning into (or across) that state isn't a one-click operation anymore — it's a request that a designated reviewer either approves, sends back, or rejects.

Stop Documenting the Rule — Enforce It​

The checkpoints you already care about — Active, Done, Approved, whatever your team calls them — can now refuse to be reached without sign-off. Mark a workflow state as Requires review and TestPlanIt does the rest. Authors see the gate. Reviewers see the gate. Nobody has to remember it's there.

Every Decision, Attributed​

Approvals are tied to a specific reviewer, on a specific date, for a specific transition. Assignees can be named individuals or roles — "QA Lead," "Compliance Reviewer" — and a new Can approve permission lets administrators decide exactly who's eligible per area: Test Cases, Test Runs, Sessions. Approvals are one-shot and consumed by the transition they were granted for. The record an auditor sees is the record that actually happened.

Each Gate, Its Own Signature​

If your workflow has two gated states, a case that crosses both gates needs both signatures — not just the last one. When your compliance posture says "tech lead approves Active, release manager approves Done," that's what shows up on the record. We considered the looser model and rejected it. The auditors who matter would too.

Nobody Has to Chase Anyone​

Reviewers know the moment work lands on their plate. Requesters know the moment a decision lands on theirs. Requests that sit too long get nudged automatically — in-app, by email, and over webhooks into Slack — until they're decided. No spreadsheet of pending reviews. No Friday-afternoon "hey, did you ever look at…" DMs. The workflow chases itself.

Safe to Turn On​

Gating workflow transitions is a meaningful behavior change, so the feature ships off by default at every level. A system admin opts the org in. Each project administrator opts that project in — pilot one team without disturbing the rest. Only the states you explicitly mark Requires review trigger anything. And every switch is non-destructive: turn the feature off mid-flight and in-flight requests wait quietly until you turn it back on.

Full reference in the Review & Approval guide.

Upgrade to v0.30.0​

Pull the latest, install, generate, and build. Docker users can pull the latest image. Full upgrade notes are in the release notes.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

Every test team has the same shelf of near-duplicate test cases. "Login — valid user." "Login — empty password." "Login — wrong password." "Login — locked account." "Login — SSO user." Same steps, same expected outcomes, different inputs. Multiply that pattern across a typical product and the repository fills up with copies of the same test case wearing slightly different hats.

It's not a quality problem — those scenarios all matter. It's a maintenance problem. When the flow changes, you edit one case and forget the other six. When someone joins the team they can't tell which "Login" case is canonical. When a run completes, the report doesn't surface "which input combinations did we actually cover this sprint?"

TestPlanIt v0.29.0 ships parameterized test cases. Write the case once. Attach a table of input rows. Each row becomes an iteration with its own status — and the results roll up to a single case in your report.

If you're already using shared steps, this is the missing other half: shared steps reuse the same steps across many cases when the flow is identical; parameterized cases reuse the same case across many input rows when the steps stay the same but the data changes.

One Case, Many Rows​

Open any test case and click Configure Parameters. Declare the named inputs your case needs — username, attempts, country_code, whatever the case uses. Drop the parameter names into your step text wherever you used to hard-code a value. Add a table of rows: one column per parameter, one row per scenario you want to cover.

When the case runs in a test run, every row becomes an iteration — a separate result line with its own status from your project's workflow, its own notes, its own evidence. A row labeled "Locked account" shows up as a discrete result. So does "SSO user." So does "Wrong password attempt #3." Open the case in the run and you see them stacked: which inputs passed, which failed, which still need testing.

Maintenance collapses. Change the steps once, the iterations all pick up the change. Add a new input combination, it's one new row. Retire a scenario, delete a row.

Shared Datasets: The Network Effect​

A lot of those input tables aren't unique to one case. Your list of supported browser/OS combinations gets used in five different flows. Your roster of test users gets reused everywhere. Your set of edge-case email addresses shows up in every signup-related case.

Shared datasets let you author that table once at the project level and assign it to every case that needs it. Each case maps the shared dataset's columns to whatever names it uses internally — same table, different parameter names, no duplication.

When the shared dataset is updated, every case picks it up on the next run. Need to add a new browser to the matrix? Edit one row, everything tested against it next sprint.

Datasets are also versioned. Every save creates an immutable snapshot, so a test run completed last quarter stays readable even after the dataset has been edited and republished. You can pin a case to a known dataset version when you're in the middle of a migration and don't want surprises.

The Iteration Matrix Report​

Per-row results unlock a kind of report you couldn't really build before: a matrix of cases × configurations × input rows, color-coded by status, all in one view.

Did Chrome on Windows pass every login scenario this regression? One look. Did the "Locked account" row fail across every browser? One look. Are there configurations you've never actually tested for a critical case? They show up empty.

The matrix is part of TestPlanIt's Report Builder. Drag it onto any report dashboard, point at the test runs you want to summarize, and export to CSV when you want to bring it into a meeting or attach it to a release sign-off.

CI Already Knows Which Row Failed​

If you're running parameterized tests in JUnit, TestNG, xUnit, NUnit, or MSTest, your test framework already emits a property or attribute that says which row of the data provider this result belongs to. TestPlanIt reads that signal directly. Upload your JUnit XML from CI and each iteration lands in the right row of the right test case automatically — no scripts, no hand-mapping.

Different teams call this property different things — iteration, dataRow, iterationIndex, whatever your CI emitter uses. The project settings let you configure the names TestPlanIt should recognize. Out of the box it looks for the most common name; add yours if you've standardized on something else.

Linked Issues That Carry the Context​

The single most annoying part of triaging a parameterized test failure used to be reproducing it. "Login failed" is not a bug report. "Login failed for user [REDACTED] on iteration 3 of 7, with these parameter values, in this test run" — that's a bug report.

When you link an issue from a failed iteration, TestPlanIt pre-fills the description with exactly that: the iteration's title, a table of parameter values for that row, and a deep link back to the iteration in TestPlanIt. Jira gets a real Jira table. GitHub gets a real markdown table. Azure DevOps gets a real HTML structured description. You edit before submit if you want; otherwise click Create and the ticket lands with everything the developer needs.

The description is translated to the issue-filer's preferred language, so a French QA engineer files a French description for the French developer who's about to read it.

Sensitive Values, Handled​

Test data sometimes includes passwords, API tokens, payment card numbers, customer PII. We give you a Sensitive flag per parameter. Mark the column once and TestPlanIt masks the value as •••••• everywhere in the UI for users who don't have explicit permission to read it, and replaces it with [REDACTED] in CSV exports and pre-filled issue bodies.

There's no new permission to teach your team. The existing Test Case Restricted Fields and Test Run Result Restricted Fields role permissions you already use for masking other fields gate this too. Grant once at the role level and the right people see the right things across every surface.

For everyday "share-my-screen-in-a-meeting" privacy, this is exactly what you need. For real production secrets, fetch them at execution time from your secrets manager rather than embedding them in test data — same rule as always.

Where to Find It​

The whole feature surface lives under one menu entry: Project Settings → Test Case Parameters. Shared datasets are managed there. CI iteration property names are configured there. Per-case parameters and inline owner-bound datasets are authored from inside each test case via Configure Parameters. Run results, the matrix report, and issue linking all light up automatically as soon as a case has parameters.

The full user guide is at Parameterized Test Cases.

Upgrade to v0.29.0​

Pull the latest, install, generate, and build. Docker users can pull the latest image. Full upgrade notes are in the release notes.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

TestPlanIt v0.27.0 ships full UI localization in 13 languages.

The Languages​

The full list, in the language picker order you'll see in your profile:

How It Works​

Switch languages under Profile → Preferences → Locale. The entire UI — navigation, forms, tables, and notifications — updates to match your selected language.

Date format, time format, and timezone are separate preferences you control independently, so you can use German UI with US date formatting, or any other combination that fits how you work.

Translations are managed through Crowdin using machine pre-translation as a baseline. The source strings are always English, and we use a Crowdin glossary to protect brand names and technical terms from being altered during translation.

Contributing Translations​

If you spot an awkward translation or want to improve coverage in your language, we welcome contributions through our Crowdin project. No pull request needed — join the project directly and suggest improvements in the Crowdin editor.

If you'd like to see a language that isn't listed yet, open a GitHub issue and we'll add it to the Crowdin project.

Upgrade to v0.27.0​

Pull the latest, install, and build. No database migrations are required beyond what the standard upgrade process covers. Full upgrade steps are in the upgrade guide.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

The TestPlanIt MCP Server changes that.

What it is​

MCP stands for Model Context Protocol — a standard that lets AI assistants connect to external tools and read or act on live data. With the TestPlanIt MCP Server installed, Claude, Cursor, or any MCP-compatible AI client can query your TestPlanIt account directly during a conversation.

You don't paste anything. You don't switch tabs. The AI asks TestPlanIt, gets real data, and uses it to answer your question.

What you can actually do​

Here are the kinds of conversations you can have once it's set up.

When a ticket lands:

"Add test cases for JIRA-1234 and put together a test run for those cases, plus any other cases that validate that nothing it touches has regressed."

The AI looks up the ticket, reads what it describes, and creates test cases for the new behavior — writing them directly into your repository. Then it searches your existing test suite for cases in folders related to what the ticket describes, builds a run with the new cases and the relevant regression cases together, and links everything back to JIRA-1234. You go from ticket to test run without opening the TestPlanIt UI.

Before a release:

"Which test cases in the Authentication folder haven't been run in the last two weeks?"

The AI checks your repository and test run history, finds the cases that are overdue for execution, and gives you a prioritized list — without you building a filter or exporting a report.

During a sprint:

"How much test coverage do we have for the checkout flow? What's failing?"

Instead of navigating to the repository, building a filter, switching to test runs, and correlating the results yourself, you get a summary in the chat.

After a QA session:

"Summarize everything we found in today's exploratory sessions. Any patterns across sessions?"

The AI reads the session results and notes, finds the common themes, and drafts a summary you can paste into a ticket or a standup.

When planning:

"How much work is left in the current milestone? Which milestones are at risk?"

It looks at milestone completion status, linked test runs, and open sessions and gives you a straight answer.

Why this matters for QA teams​

QA teams spend a lot of time translating between systems. A developer asks a question in Slack, you go look it up in TestPlanIt, come back with an answer, and then get asked a follow-up that requires another lookup. It's not a problem with TestPlanIt — it's a problem with information living in one place and conversations happening in another.

The MCP Server collapses that gap. When your AI assistant can read your test data in real time, it becomes a useful participant in planning conversations instead of a writing tool you have to separately feed information to.

It also means you can ask questions you'd normally skip because the lookup cost isn't worth it. "How many test cases did I write last month?" is a simple question, but getting the answer manually requires a filter, maybe building a report, and a few minutes. With the MCP Server, it's one sentence.

What the MCP Server can do​

The initial release covers the full read and write surface of TestPlanIt:

• Test cases — search, filter by folder, tag, status, creator, date range; create, update, delete
• Test runs — create runs, add cases, submit results, update state; read details, case results, step results, and linked issues
• Sessions — create and update exploratory test sessions; read results and notes
• Milestones — create, update, and mark complete; read completion status, linked runs, and descendant structure
• Repositories and issues — linked cases, external issue connections
• Issue links — link or unlink test cases, sessions, test runs, and results to issues in a single call

Together these close the loop on the full testing workflow in a single conversation: find an issue, create cases for it, and build a test run — without leaving the chat.

All operations are scoped to your API token's permissions. The AI can only see and modify what your account can access.

Getting started​

The MCP Server is a standalone package you install once. It authenticates with your existing TestPlanIt API token and works with any MCP-compatible client — Claude Desktop, Cursor, and others.

Full setup instructions are in the MCP Server documentation.

The MCP Server is open source alongside the rest of TestPlanIt. If there's a query pattern or action you'd like to see added, open an issue or discussion on GitHub.

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord

This release ships webhooks. Issues sync the moment they change in your tracker, badges and lists update live without a page refresh, and TestPlanIt events fan out to Slack or any signed URL automatically.

Inbound Webhooks: Issues That Just Stay Current​

Connect an inbound webhook to your project's issue integration and the conversation flips from pull to push. When someone updates a Jira ticket, a GitHub issue, or an Azure DevOps work item, the linked TestPlanIt issue updates within seconds. Status badges flip color. Lists reorder. Detail panes refresh themselves while you're still on the page.

If an event comes in for an issue that hasn't been imported yet, TestPlanIt creates it for you. No empty states, no "issue not found," no manual import.

Setup is a few clicks per project. TestPlanIt walks you through it for each provider.

Outbound Webhooks: Push Anywhere​

Outbound webhooks go the other way. Test runs, sessions, cases, and issue activity all become events you can ship to any URL.

Two destinations are supported on day one:

• Slack. Paste a Slack channel URL and TestPlanIt posts formatted updates with links back to the relevant page. Great for QA channels that want a feed of run completions or regression failures.
• Any signed HTTPS URL. Point at a CI gate, a dashboard, an automation tool, or anything else that can verify a signed POST. The receiver gets a JSON payload signed with a shared secret you control.

Each project can run as many outbound webhooks as it needs. Pick which event types each one subscribes to. Want a "regressions only" Slack post and a separate "everything" feed to a custom dashboard? Two configs, done.

Live UI Updates​

Inbound webhooks would be half a feature if you still had to refresh the page to see the result. So you don't. Every browser tab viewing a project receives updates the instant TestPlanIt does, with no extra clicks.

If your deployment was already configured for our existing real-time notifications, this works out of the box. If not, the deployment doc covers what's needed.

Health, Deliveries, and Replay​

A webhook that silently fails for a week is worse than no webhook. Every webhook gets a health badge (Healthy, Degraded, or Disabled), a delivery log showing recent activity and any errors, and a Replay button on outbound deliveries so a Slack outage or transient 502 doesn't lose a notification permanently. Bulk replay is available too. If an endpoint goes dark long enough to auto-disable, one click brings it back.

Security Defaults That Mean It​

Webhook security is the kind of thing teams either nail on day one or paper over forever. We picked the former.

• Secrets are encrypted at rest and only revealed once at creation, so a leaked log doesn't expose them.
• Webhook URLs containing access tokens are redacted before they ever hit a log file.
• Outbound URLs are HTTPS-only.
• Every outbound payload is signed; replay attacks are blocked by deduplication.
• Rotating an outbound secret is a zero-downtime operation: the new secret takes effect immediately while the old one stays valid until you retire it.

If you switch your project's issue integration to a different provider, or remove the integration entirely, the inbound webhook is removed in the same step. This stops a stale webhook from sitting around for a provider it no longer matches.

Getting Started​

Webhooks live under Project Settings → Webhooks. The full per-provider walkthrough, including the exact events to subscribe to in Jira, GitHub, Azure DevOps, and Slack, lives in the webhooks user guide.

Upgrade to v0.24.0​

Pull the latest, install, generate, and build. Docker users can pull the latest image. Full upgrade steps and notes for SSE-aware deployments are in the release notes and SSE deployment guide.

Get Involved​

• Star the repo on GitHub
• Follow @TestPlanItHQ for updates
• Join our Community Discord
• Report issues and suggest features on GitHub

Thank you for using TestPlanIt!

If you've evaluated a test management tool lately, you've seen this pitch: "Generate automated tests inside the tool." "Codeless automation — no scripting required." "AI-powered test creation."

And honestly? The pitch lands. One system, one login, one place to look. For a small team on a greenfield project, it even works for a while.

But it creates problems that only become obvious once you're deep enough in to care.

What This Is Actually About​

At its core, this is an argument about separation of concerns — the same principle that shapes every other layer of modern software. A test management tool and an automation framework are two different concerns, with different audiences, different lifecycles, and different tooling requirements. Collapsing them into one system feels tidy, but so does putting your database, your web server, and your logs on a single box. It works until it doesn't, and by the time it doesn't you've built a lot on top of it.

This isn't an argument against test management tools, or even against tools that integrate with automation. Plenty of tools do the right thing: you run your test scripts in CI, they post results back, the TMS shows you coverage and trends against your test cases. A handful of tools work this way. It's the pattern the industry has mostly converged on for good reasons — and it's exactly the separation of concerns that makes it work.

The pattern worth pushing back on is different: tools that host your scripts in their own database, tools that generate scripts inside a proprietary editor, and tools whose big AI feature is "we'll write your automation and keep it here." Low-code and no-code automation platforms are the clearest examples, and they're the ones most aggressively marketed to teams that don't already have a framework in place. Those have deeper problems, and most don't show up in a two-week trial.

Low-Code and No-Code Are the Worst Offenders​

Before getting into the specifics, it's worth being blunt about the category. Record-and-playback tools, visual script builders, drag-and-drop flow editors — Katalon Studio, Testim, Mabl, Leapwork, TestComplete, BrowserStack Low-Code, and the long tail of similar products — are the archetype of this anti-pattern. The pitch is always the same: "your QA team doesn't need to write code." The reality, consistently, is that you end up with a growing library of test scripts stored in a format only that vendor understands, maintained through a UI that was designed to look friendly in a demo rather than to scale to hundreds of scripts — sometimes thousands.

The appeal is real: scripts come together quickly, manual QA can contribute directly, and the first month looks fantastic. But the tradeoff is baked in from day one. The tool can't show you what a script does without the UI. Your version control system sees a binary blob or nothing at all. Teammates can't review changes. CI can't lint or type-check anything. And when the vendor's abstractions don't fit — which happens the moment your app does something nontrivial — the tool either adds a custom-scripting escape hatch (congratulations, you're writing code now, just in a worse editor) or quietly caps what your script suite can do.

The same critique applies to low-code features that some test management tools bolt on. Even when the TMS itself is otherwise well-designed, the moment you start storing test scripts in its database you've inherited the whole problem. This is a separate issue from whether a TMS is useful — it's very much useful — but it's a strong argument for keeping the scripts somewhere else.

The Regenerate Trap​

Here's the cycle that burns teams who go all-in on low-code, no-code, or AI-generated automation hosted in the vendor's tool.

You record or generate a test script. It works. You tweak it — add waits where the app is slow, handle a dynamic element, set up test data, tighten an assertion. You've made it yours.

Then the UI drifts. A button moves, a form gets restructured, a page gets a redesign. The script breaks. And because the scripts live in a format that's hard to edit structurally, the path of least resistance is to regenerate. Regenerate, and your tweaks are gone.

Do this enough times and you notice it's not a one-time event. It's a cycle. Every UI change costs you the work you did last time. Productivity in month one looks incredible; productivity in year two looks a lot like treading water.

A Framework Beats a Generator​

Compare this to what a team running a modern automation framework does when the UI drifts.

You have a page object for the page that changed. You update the locator in one place. Every script that touches that page is now fixed. Your tweaks — waits, assertions, data setup — are untouched because they live in the script itself, where structured code separates "how to find things on the page" from "what this script is checking."

This is what Playwright's page object model looks like. It's what Cypress custom commands look like. It's what a well-structured WebDriverIO or Selenium suite looks like. The whole automation industry converged on this pattern because it works: localized changes, persistent tweaks, scripts that survive UI churn. Generators can't give you that. Their output is flat — each script is a standalone recording with locators inlined and waits hardcoded. Refactoring means regenerating. That's fine for a throwaway smoke script. It's not fine for a regression suite you'll maintain for years.

Framework Lock-In Is the Other Kind of Lock-In​

Most of the lock-in conversation focuses on the vendor — you can't leave this specific tool without rewriting your automation. Real problem. But there's a second kind of lock-in: to whatever framework and language the tool decided to support.

A lot of teams are moving from Selenium to Playwright right now. Good reasons — faster execution, better async handling, network interception, TypeScript ergonomics. If your automation lives in your repo, you can migrate incrementally: new scripts in Playwright, old Selenium scripts keep running, switch at your own pace. Same for language migrations — Java to TypeScript, Python to Go. You own the code, you control the migration.

If your automation lives in a test management tool that only generates Selenium Java, you can't. You can start writing Playwright scripts in a separate repo, but now you've got two parallel systems and the TMS has no idea the Playwright scripts exist. Every new script you generate in the tool digs the Selenium hole a little deeper. The migration path isn't "gradual" — it's "rewrite everything at once, probably never."

This is the kind of decision that doesn't feel like a decision when you make it. You pick a tool in 2023 that only generates Selenium. In 2026, the team wants Playwright. Now you're discovering that three years of recorded automation is tied to a framework you've outgrown.

When the AI Can't See Your Code​

A newer version of this problem shows up in AI-generated automation. Some tools sync generated scripts directly into a vendor's broader automation platform — one vendor owning both the generation and the execution.

The issue isn't AI. AI-assisted test script writing is genuinely useful. The issue is where the AI runs and what it can see. An AI generating scripts in a vendor's hosted editor doesn't see your existing page objects, custom commands, data helpers, or naming conventions. It produces generic code, not code that fits your project — because it has no visibility into your project. You either accept its patterns and drift from your own, or spend meaningful time adapting every output and wonder what the AI actually saved you. Either way, you can't take the work with you.

Contrast this with AI that runs against your actual repo and reads your actual code. Same technology, different position in the stack, completely different outcome.

A Note on Gherkin​

One case complicates this picture: Gherkin feature files stored in a TMS, with step definitions in the repo. Usually Cucumber-style BDD integrated with Jira.

If you're genuinely practicing BDD — three-amigos sessions, scenarios written before code, Gherkin as a collaboration artifact — storing feature files in the TMS is defensible. Scenarios are documentation that happens to be testable. For teams actually doing BDD, it can work.

The honest issue is that most teams using Gherkin aren't doing BDD. They're writing imperative Gherkin — Given I click the "Login" button / And I enter "user" in the field — which is Selenium in Gherkin clothing. Cucumber's own creators call this an anti-pattern. Hosting it in the TMS is the same proprietary-storage problem, with extra ceremony. And even for real BDD, split storage creates a silent coupling: rename a step in the TMS, step def matching in the repo breaks at the next CI run. Two sources of truth, no tooling to enforce sync.

Test Scripts Belong With the Application Code They Exercise​

A quick terminology note before this section, because it matters here: test cases are the human-readable descriptions of what to verify — the artifacts a TMS is built for. Test scripts are the automation code that executes those checks against a real system. This section is about test scripts, not test cases. Test cases can happily live in a TMS. Test scripts should not.

There's a stronger version of "keep your scripts in your repo" that's worth stating directly: test script code should live in the same repository as the application it's exercising. Not a sibling repo, not a separate "automation" project owned by QA — the same repo as the application source.

This matters for reasons the TMS-hosting pattern can't touch:

• It shifts automated testing left without a memo. When the test scripts are right there in the codebase, developers run them before handing code to QA. They don't have to remember to go check another system. A failing script shows up in the same terminal as the compile error. That nudge is worth more than any process document.
• It treats test scripts like what they are — code. Scripts get reviewed in the same pull request as the feature they verify. They get refactored when the code underneath them is refactored. They move through the same CI, the same linters, the same type checker, the same coverage tooling. The whole discipline that has made application code maintainable over the last thirty years applies to test scripts, for free, the moment they live in the same repo.
• It keeps script and application versions in lockstep. This is the one most teams underestimate until they're burned by it. You need to know which version of the test scripts ran against which version of the application. If the scripts live in a separate system with its own versioning, you're constantly asking "wait, does this script suite match the build we deployed?" When the scripts live in the repo, a git checkout gets you the exact scripts that shipped with that release. No ambiguity, no drift, no archaeology.

None of this is possible when the scripts live in a TMS database. The scripts aren't in the diff. They aren't in the PR. They aren't tagged with the release. They're in a separate universe, with a separate versioning story, maintained by people who may not even see the code change that broke them.

What You Actually Lose​

When scripts live in a vendor's database instead of version control, here's what you quietly don't have:

• Diffs, blame, and bisect — no "who changed this assertion six months ago, and why."
• Code review — modifications to code that decides whether your software ships go in without another pair of eyes.
• IDE tooling — no autocomplete across files, type checking, structural rename, or jump-to-definition.
• Local debugging — no breakpoints, no stepping through, no inspecting state.
• CI-native workflows — your pipeline runs against a checkout of a repo; scripts in a TMS have to be reached into from outside.
• Portability — your cases are exportable; your scripts are a rewrite.

What to Look For in a Test Management Tool​

If you're evaluating tools, here's the lens that cuts through most of the noise: a test management tool should make your automation visible, not own it. It should know which test scripts exist, which requirements they cover, and what happened when they ran. It shouldn't be the canonical home of the scripts themselves.

Look for:

• Results ingestion from your CI pipeline — whatever framework, whatever language.
• A way to link cases to automation without hosting it — stable IDs, tags, annotations.
• Portable export — your cases leave as structured data; your scripts were never in the tool in the first place.
• Framework and language agnosticism — today's choice shouldn't block next year's migration.

Avoid:

• Proprietary script editors sold as a feature.
• Codeless automation stored in formats you can't export to real code.
• AI generation that outputs to the vendor's ecosystem instead of your repo.
• Tight coupling between the TMS and one specific framework or language.

The Bottom Line​

Test management is valuable. Automation is valuable. The problem is when one tries to own the other — when a tool ignores separation of concerns and stuffs everything into a single system because a unified demo sells better than a well-designed seam.

Keep the scripts in your repo. Let version control, code review, and your IDE do what they've been good at for decades. Let CI run the test scripts. Let the test management tool do what only it can do: aggregate script results across frameworks, link test cases and scripts back to requirements, track coverage, give you structured visibility a code repo alone can't. That's the seam worth defending.

Tools that own your automation own you. Tools that respect the separation between test management and test code — and make the two talk to each other through stable, boring interfaces — give you leverage.

Why a Security Page?​

Until now, password requirements were limited to a minimum length check during signup. There was no way to enforce character complexity, prevent password reuse, expire old passwords, or lock out accounts after failed login attempts.

For teams managing sensitive test data — especially those working toward SOC 2 or ISO 27001 compliance — these are table-stakes controls. v0.22.0 fills that gap with a single admin page that covers the full lifecycle of password security.

What's New​

Configurable Password Policy​

Navigate to Admin → Security to configure:

• Minimum password length (8–128 characters)
• Character requirements — uppercase, lowercase, numbers, and custom special characters
• Password history — prevent reuse of the last N passwords (up to 24)
• Password expiration — force password changes after a configurable number of days (up to 365)

All settings use slider controls for quick adjustment, with the current value displayed alongside each slider.

Account Lockout​

Protect against brute-force attacks with configurable lockout rules:

• Lockout threshold — lock accounts after 1–20 consecutive failed attempts
• Lockout duration — keep accounts locked for 1–60 minutes

Enforcement Actions​

Sometimes you need to act immediately — after a security incident, a compliance audit, or when offboarding a user from credential-based access.

• Force Password Change — require an individual user or all internal users to set a new password on their next login. Available from the user table's three-dot menu and as a bulk action on the Security page.
• Revoke Password — remove a user's password entirely, limiting them to SSO or Magic Link authentication. Useful for transitioning users away from password-based login.

Both actions include confirmation dialogs, guard against self-lockout (you can't force-change or revoke your own password), and are fully audit-logged.

Password Strength Indicator​

Every password form — signup, change password, and forced password change — now displays a real-time strength indicator:

• A four-level strength bar (Weak, Fair, Strong, Very Strong) powered by zxcvbn, which evaluates password strength using pattern matching and entropy estimation rather than simple rule checks
• A policy checklist that shows which requirements are met as the user types

This gives users immediate, actionable feedback before they submit — reducing failed submissions and encouraging stronger passwords.

Server-Side Enforcement​

All policy checks are enforced server-side, not just in the UI. The password validation pipeline runs on every password change endpoint, checking minimum length, character classes, special characters, and password history. Slider ranges in the UI match the server-side validation bounds, so there's no mismatch between what the admin configures and what the server enforces.

Try It Out​

Upgrade to v0.22.0 and navigate to Admin → Security to configure your password policy. See the Security Settings documentation for a full walkthrough of every setting.

Why Generate from a URL?​

The Generate Test Cases wizard already supports issues (Jira, GitHub, Azure DevOps) and pasted requirements documents. But not every feature starts with a ticket. Sometimes the spec is a product page, an API reference, a competitor's app, or a staging deployment with no linked issues.

With URL-based generation, you skip the copy-paste step entirely. Give TestPlanIt the URL and let the AI read the page directly.

How It Works​

Open the Generate Test Cases wizard from any repository folder, select the From URL tab, and enter a URL.

Two Modes​

• Application — Treats the page as a live application. The AI generates functional test cases for the UI, workflows, and features it finds.
• Requirements — Treats the page content as a requirements or specification document. The AI generates test cases that verify the described functionality.

Multi-Page Crawling​

Enable Follow Links to crawl beyond the seed page. TestPlanIt follows same-domain links up to your configured depth and page limits (max 5 levels deep, up to 50 pages).

As the URL is crawled you'll see a progress bar as each page is fetched. Once crawling finishes, the AI processes each page sequentially, streaming test cases into the review step as they're generated.

Crawled pages respect robots.txt, skip duplicate content, and detect single-page applications that may need JavaScript rendering.

Real-Time Streaming​

Test cases appear as collapsible cards the moment the AI starts generating them — you don't have to wait for the entire batch to finish. Each card shows the test case name and expands to reveal all fields, steps, tags, etc. You can immediately start reviewing test cases.

For multi-page crawls, the footer shows which page is being processed and how many test cases have been generated so far.

Per-Page Folders​

When importing test cases from multiple pages, each page's cases are placed in their own subfolder (named after the page). This keeps things organized when a crawl produces dozens of test cases across different sections of a site.

Safe to Close​

Progress is saved after each page completes. If you close the wizard mid-generation, the test cases from completed pages are preserved. When you reopen the wizard, the Recent Generations list shows your previous crawls with page counts, test case counts, and timestamps. Click any entry to review the generated test cases.

Results are cached for 7 days. You can remove entries you no longer need from the list.

Streaming for All Sources​

While building the URL feature, we brought the same real-time streaming experience to issue and document generation. Previously, test cases from issues and documents appeared all at once after the AI finished. Now they stream in incrementally — you see partial field values as they arrive, just like with URL generation.

Performance​

Generating lots test cases used to cause browser rendering/memory issues. Now hundreds of test cases are rendered smoothly each their own collapsible cards. The collapsed view shows the name, folder label, and tags. Click the chevron to expand and see all template fields and steps. This makes it much easier to scan through a large batch before importing.

Interactive Tag Editing​

Tags in edit mode now use interactive badges instead of a comma-separated text input. Each tag appears as a removable badge — click the X to remove it. Type and press Enter or comma to add a new tag. Backspace removes the last tag when the input is empty.

Try It Out​

Open the Generate Test Cases wizard from any repository folder, switch to the From URL tab, and paste a URL. Start with a single page to see the quality, then try multi-page crawling for broader coverage.

Read the full documentation

Multi-Configuration Sessions​

Test Runs have supported multiple configurations since day one — select Chrome, Firefox, and Safari when creating a run, and TestPlanIt creates one run per environment, all linked together. Sessions now work the same way.

When creating a session, the Configurations field is now a multi-select. Pick two or more configurations and TestPlanIt creates one session per configuration, sharing the same name, template, milestone, tags, and issues. A configuration group ID links them so you can see they belong together — look for the link icon next to the session name in the list.

On the session detail page, a configuration selector appears above the results area (just like on test run details). Select a different configuration to navigate to that sibling session instantly.

Learn more about multi-configuration sessions

Session Duplication​

Need to re-run an exploratory session for a new sprint or milestone? Click Duplicate from the session's context menu. The Add Session dialog opens pre-populated with all the original session's metadata — name, template, configuration, milestone, state, assigned user, description, mission, tags, issues, and custom field values. Modify what you need and create.

Results are never copied. The duplicate starts fresh.

You can also select multiple configurations during duplication to create one session per environment in a single step.

Learn more about session duplication

PDF Export for Sessions and Test Runs​

Both Sessions and Test Runs now have an Export PDF button on their detail pages. One click generates a portable PDF that includes:

Session PDFs:

• All metadata (template, configuration, milestone, state, assigned user, estimate, elapsed time)
• Description and mission
• Tags, linked issues (with keys and titles), and custom field values
• Every session result with status, notes, elapsed time, custom fields, linked issues, and embedded image attachments

Test Run PDFs:

• All metadata (configuration, milestone, state, forecasts)
• Description and documentation
• Tags, linked issues, and custom field values
• Every test case (ordered by run order) with execution status, assignee, results, step-by-step details, comments, custom fields, and embedded attachments

The export button appears in the header alongside Edit, Complete, and Duplicate — shown as compact icon buttons that expand to reveal their label on hover. Export is available on both active and completed items, including JUnit/automated test runs.

Learn more about session export | Test run export

Other Improvements​

• MultiAsyncCombobox fixes: "Select All" now shows the accurate total count across all pages (not just the current page). Selected items display with readable names and ellipsis truncation instead of clipped icons.
• Session list: A new Configuration column shows each session's configuration, matching the Test Run list layout.
• Prompt config editor: Fixed a bug where LLM integration selections weren't persisting after save when editing prompt configurations.
• Copy/move collision detection: Improved name collision detection for the copy-move preflight check.

Try it out and let us know what you think.