33 posts tagged with "Announcement"

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.

A test result is a claim: "this passed," "this run is done." When a release manager — or an auditor — asks who said so, when, and whether anyone changed it afterward, the answer needs to live in the tool.

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.

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.

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.