Today we're releasing TestPlanIt v1.2.0.

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.

It's the day before a release. Someone asks, "Did we test the new permissions model?" The room goes quiet, someone opens a spreadsheet, and someone else says "I'm pretty sure that got covered last sprint."

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.

Today we're releasing TestPlanIt v1.1.0.

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.

Today we're releasing TestPlanIt v1.0.0.

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.

Import a thousand automated test results into most test management tools and you get a thousand rows that say passed or failed — against a test name and nothing else. The "test case" is an empty shell. If you want it to actually describe what was tested, someone types the steps in by hand.

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.

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.

You hire someone. HR adds them to your identity provider. They walk into the office on Monday, sit down, open their laptop, and TestPlanIt is already there waiting for them — the right groups already attached, no "hey can you add me to the right project?" Slack DM.

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.

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

You have hundreds of manual test cases and finite bandwidth to automate them. Which ones first? Most teams answer by gut feel — or by whichever case failed last regression. But the case that runs in every regression and recovers an hour of tester time each run beats the one that bit you last sprint and won't bite again for six months. You can't see that on a list.

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.

If your data team treats test execution like any other event stream — coverage trends in Snowflake, defect heatmaps in BigQuery, regression dashboards in Databricks — you've probably written a custom ETL job to scrape pages of paginated JSON out of your test management tool.

We just made that job a one-liner.