What's next in TestPlanIt 1.1

Every requirement rolls up the latest result of every case covering it, through its whole subtree — Passed, Failed, Not run or Uncovered — with per-status counts and a drill-down that links each result back to the run it came from. Scope the rollup to a milestone or configuration to ask “is this covered on this release?” When a requirement’s content changes after a linked case last ran, the link is flagged Suspect: re-executing the case clears it automatically, or dismiss it after review.

Three pre-built reports put it in front of stakeholders. Requirement Traceability pairs every requirement with its cases and their latest results; Requirement Coverage Gaps ranks your coverage debt — and generates test cases straight from a gap row; Requirement Coverage Changes compares two points in time. Because the live matrix moves with every execution, a Snapshot freezes it — every requirement, its covering cases and their results, stamped with who captured it and why — so release sign-off has evidence, not a screenshot.

Point TestPlanIt at the repository of the application under test — GitHub, GitLab, Bitbucket, Azure DevOps or Gitea — 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: no coverage agent, no build step, no instrumentation. A project whose application spans several services can connect a repository per service.

Every selection explains itself. Code Pins tie a test case to a file, line range, symbol or glob — added on the case page or declared in the repository with an @testplanit annotation or a map file. A commit that names a ticket pulls in every case linked to it. Keyword matching, prior runs that covered the same change and an AI ranking against the diff fill in the rest, each with its own reason badge. Or let the repository start the analysis: a pull request opened or a push to your base branch runs it and composes a test run of the affected cases, named after the event.

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, or however you like — click Execute automated cases, and the automated portion runs in your CI while testers pick up the manual cases. A single automated case gets Execute automated test for the same thing in miniature. Manual and automated results share one checklist with one status per case, and the newest result wins.

TestPlanIt starts the job on an execution target the project configured — a GitHub Actions workflow, a GitLab CI pipeline, or a signed webhook for Jenkins and anything else — and hands it the run id plus a URL where the job fetches its plan of cases. 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, your job turns them into a grep or filter expression, and the reporter or CLI you already use reports back into that run.

Organizations rarely have one identity provider. 1.1 lets Okta manage your employees and Entra manage your contractors on the same TestPlanIt instance: each user and group records which IdP provisioned it, each IdP sees only its own directory, and a write across that line is refused and logged rather than silently overwriting.

Rotate a SCIM token in place with an overlap window — from an immediate cut-over to 30 days — so provisioning never breaks between re-keying and pasting the new value into your IdP. Map IdP-asserted roles to access tiers, taking precedence over group mappings so contractors stay at User even inside an Admin-mapped group, and scope a group to the projects it works on instead of the whole instance.