Qase Product Updates: September 2026

Most of a QA team's week goes into the testing itself. The rest is coordination: chasing a review, asking for a chart nobody has built yet, working out which repository a project should see.

In September we tried to make the latter a lot easier. Here's what shipped.

Pillar 1: Reviews that look after themselves

Case Review, five updates in one month.

Test case review works like a pull request for your repository: an author proposes a change, reviewers approve it, and the approved change is merged into the test case.

The review shows the diff. Opening a review used to mean reading both versions of the case and spotting the differences yourself. The page now highlights them, down to individual words, across titles, descriptions, preconditions, step fields, and text custom fields. Steps get Added, Deleted, and Modified badges, including steps that moved.

Note: converting a case between Classic and Gherkin shows up as a single block change, without word-level highlighting.

It shows where the case lives. The full suite path sits under the review title, each level clickable, so a reviewer knows what they're looking at without opening the repository in another tab.

Reviewers get assigned automatically. Set one or more default reviewers per project in Project settings, under Repository. When an author submits a case without picking anyone, the defaults are assigned. You can also nominate several reviewers on a single review now.

Full approval means merged. Turn on Auto-merge in the same settings page and a review merges the moment it collects its last required approval, with no final click. An open "request changes", a stale proposal, or a reviewer without save rights holds the merge. It's off by default and needs at least 1 required approval configured, so nothing changes until you switch it on.

And it tells you what happened. When someone approves, requests changes, merges, declines, or edits a review, the author and every reviewer are notified, in-app and by email, with a link straight to the review. You're never notified about your own action, and a new Test Review group in notification settings lets you turn Decisions and Edits off separately.

Up next: sending a batch of cases through review in one go. The review docs cover every setting above.

Pillar 2: GitHub access and Jira upkeep

GitHub Access Control.

One GitHub installation used to give every Qase project the same view: any repository the integration could reach was searchable and linkable from anywhere in the workspace. For a workspace with one product, that's fine. For a workspace that holds one client's project next to another's, it means people on one project can search and link to the other's repositories.

An admin can now map repositories to projects, and a project sees only the repositories it's been given. To set it up, go to Apps, then GitHub, then Access Control, turn the feature on, and pick the repositories each Qase project is allowed to see. It's off by default. Available on Teams and Enterprise, the same plans as Jira Access Control. The GitHub docs walk through it.

Jira Cloud moves to Forge. Atlassian has deprecated Connect, the framework the Jira Cloud integration was built on, so we've started migrating it to Forge. The migration is automated and nothing is required from you. If you'd rather not wait, open the Qase app in your Jira administration settings and click Update. The integration keeps working as it always has.

Pillar 3: Build the widget instead of asking for it

Custom Widget Builder.

Dashboards came with a library of ready-made widgets. Good ones, but a fixed list, and the question we heard most was "do you have a widget for this?" Too often the honest answer was "file a request."

You can now build it yourself. Click Add widget, choose Create custom widget, and pick what to count: test cases, run results, defects, test runs, or requirements. A single widget holds up to 5 of those blocks. Filter each block by the entity's own fields or by your custom fields, group it by the field you want as the axis, then segment the whole widget by a property every block shares, like priority, so each block splits the same way. A widget takes up to 10 segments. Render it as a bar chart, line chart, donut, or table. QQL widgets work exactly as before. How the builder works.

QQL groups by custom fields. The ask was simple and the fix wasn't, because it needed a change in how we store and process analytics data underneath. That groundwork is done, and this is the first thing built on it. Two limits for now: one custom field per group by, and custom fields can't yet be arguments to aggregate functions like sum. Hit either one and you get a plain error message, so a chart never quietly shows the wrong number.

Júlia wrote the full walkthrough, including what the builder doesn't do yet: We set the widgets free.

Pillar 4: The platform under load

Per-plan API rate limits are live.

More of the traffic hitting Qase is machines: reporters posting results from CI, MCP clients, agents generating tests at whatever speed the model runs. That's the point of the platform. Test case results alone grew from 3 million a day in March to 8 million a day in September, so we're putting limits in place now to keep every workspace fast as that number climbs.

Every plan now has a per-minute limit, set at or above comparable tools at every tier. Limits apply per workspace and are shared across all of its API tokens: Free has 150 requests a minute, Teams has 600, and Enterprise has 1,000. We don't envisage that you'll ever hit these limits. If you think you might, talk to us and we offer custom limits on Enterprise. Short bursts up to 2x the limit are allowed for up to 10 seconds. Go over and you'll get an HTTP 429 with a Retry-After header and the usual X-RateLimit-* headers, so a well-behaved client backs off on its own. There's no separate monthly cap. If your paid workspace was already running above its new limit, you're on a temporary raised limit sized to your recent peak, so nothing broke on day 1. Talk to support or your CSM about a custom limit. The numbers are on the pricing page.

Fast got faster. Two performance rounds went into the parts of the platform that carry the most traffic. The first went after test run estimates and statistics. Measured at p99, the slowest 1 percent of requests, creating a run through the API went from 6.6 seconds to 0.7, the run list from 4.3 seconds to 2.7, and the run dashboard estimate from over 10 seconds to 4.5. No endpoint got slower. The second round reworked the results endpoint so it no longer counts and scans a project's entire result set on every call. Requests slower than a second dropped by about half; the median didn't move, by design, because the work targeted the tail.

14 MCP server releases. The MCP server went from v2.2.3 to v2.7.5 in September. The changes an agent user will notice: it can manage projects and custom fields, it uploads several attachments in one request, and it tells you the difference between "your plan doesn't include this" and "you don't have permission", which used to look the same. It refuses a destructive action when the confirmation prompt can't be delivered. It's also listed in the official MCP Registry.

And the CLI. qasectl 0.5 lets you point the CLI at a different API host, which matters if your workspace isn't on the default cloud cluster.

Quality Supervisor, now with 6 skills. We introduced Quality Supervisor last month with 4 of its skills. Two more are public. Change-impact analysis diffs a branch, traces what the change reaches, and drafts a regression checklist grounded in your existing cases. It's the one skill that reads your code, and you decide what to run. Quality Pulse is an HTML report card for any period: execution, pass rate, defect backlog, case activity. One fix worth being open about: on Windows machines without Git Bash, the hook that blocks deletion tools wasn't running, so the guard we described last month had a gap there. It now has a PowerShell twin, so at least one of the pair runs everywhere. The help center article has the install steps.

Pillar 5: Fewer empty trials

For whoever signs up next.

A smaller one, but if you administer a workspace it affects you. When someone signs up with your company's email domain, Qase now checks for a waiting invite and offers to join that workspace. If there's no invite but the domain already belongs to a paying workspace, they get a short message to send to their admin asking for access, instead of landing in an empty trial that isn't their team. We don't notify admins ourselves; who joins is the admin's call. Public email providers are excluded.

Most of this month's work sits in the gaps between tasks: reviews that route and merge on their own, charts you build yourself, and an API tuned for the traffic ahead. Auto-merge and GitHub Access Control stay off until you turn them on. Everything else is already running.

Happy testing!