Brad DerManouelian

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.

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.

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.

Test management is a global discipline. Your QA team might be spread across São Paulo, Amsterdam, Warsaw, and Tokyo, and until now they've all been working in English whether they wanted to or not. That changes today.

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

Most of the time, your AI assistant and your test management tool live in completely separate worlds. You're in Claude or Cursor, you want to know something about your test coverage, and you either have to go look it up yourself or paste a wall of data into the chat and hope the AI makes sense of it. The AI is smart but blind — it can't see your TestPlanIt data, so it can't actually help you with it.

The TestPlanIt MCP Server changes that.