Defects Board, Defects in Analytics, Milestone Insights, Comment Mentions, and More

Defects

Defects Project Board

Every project now has a Defects page listing the bug-tracker issues raised against your failing tests. Defects usually appear on their own when a tracker issue is attached to a failed test run, while New Defect files a fresh issue in your tracker and Add Issue as Defect registers one that already exists, by URL or ID.

Picture a nightly regression that starts failing on Monday. Someone files a Jira bug, and by Thursday the same issue has surfaced in four more runs across three different suites. Until now that bug existed only as a link buried inside individual test runs, and understanding its real reach meant opening each run in turn and piecing the picture together. Now it's one row on the Defects page: a single defect, with every affected test case listed underneath it. When a teammate closes it in Jira on Friday, the row closes here too.

Available for Jira, GitHub, GitLab, Linear, Azure, YouTrack and plain links.

Defects in Analytics

The Defects report under Analytics answers the question the Defects board doesn't: not what bugs are open, but which of my tests are blocked, and by what. Rows here are test cases, with their defects nested underneath — expand a test to see every defect holding it back, each with its severity, open or closed status, and a link out to the tracker.

Choose how defects reach a test with the data-source selector:

• All Defects merges both routes and counts a defect once even when it's linked twice
• By Tests shows only defects attached to the test case itself
• By Test Runs shows only those raised on that test's runs

It's a quick way to separate bugs someone filed against a test from bugs the test actually caught.

Milestones

Defects on Milestones

Milestones now carry a Defects tab alongside Runs, Tests, Requirements, Plans and Users, so the bugs standing between a milestone and its finish line sit with everything else you track against it. Since milestones span projects, so does the tab.

Each defect shows its status, severity and the date it was opened, with the tracker it came from marked on the title. Click through to open the defect in your project's Defects board, or jump straight to a project from its section — either way, a release manager can see which teams are still carrying open bugs against the milestone without opening a project at a time.

Users on Milestones

Milestones now carry a Users tab showing who is working on them and how far each person has got. Users are grouped by project, and each row gives you the tests that person created in the milestone, the tests currently assigned to them, the tests they've executed, and a progress bar of completed against assigned — so you can see whether the work is spread evenly and where a milestone is waiting on someone.

Manage Milestone Types

Milestones are grouped by type and you can now review and tidy that list. A gear icon beside the Type field on a milestone form opens Manage milestone type, showing the built-in types (Milestone, Release, Sprint) alongside every custom type in use across the company.

Creating a type stays where you need it: type a new name into the Type field on a milestone and it exists once the milestone is saved.

Collaboration

Comment Mentions and Notifications

Comments now reach the people who need to see them. Type @ followed by a teammate's username in a comment on a test or suite and they're notified right away — so a question aimed at someone doesn't sit unread in a thread they had no reason to open.

Threads keep everyone who's already involved in the loop. Post a comment on a test or suite and everyone who has commented there before is notified that the conversation has moved on.

Notifications arrive where you're working. A bell in the left navigation collects them, with a dot when something is unread and new arrivals appearing without a reload. Email follows five minutes later — and is skipped entirely if you've already read the notification in-app by then, so you don't get told twice. You can turn email off in Account settings.

Runs and Execution

Multi-Environment Run Matrix

Configuring a run across several environments is clearer now, particularly when you're building environment groups. Multi-environment runs let you execute the same set of test cases across different browsers, operating systems, devices or stages, so cross-platform compatibility and deployment consistency are validated from one set of tests instead of duplicated suites. Environments are defined once in project settings using the {category}:{value} format — Browser:Chrome, OS:Windows, Stage:Dev — and combined into groups when you launch.

Environment configurations can also be passed at runtime from your CI/CD pipeline, so the same setup drives automated runs triggered by branch or deployment stage. Full details are in the Environments guide.

Editing Results in a Finished Run

Release days rarely end on the run that closed. A test fails, someone ships a last-minute fix, you verify it by hand — and the finished run still shows red, standing between you and a deploy decision. You can now set a different status on an individual result inside a run that has already finished, so a single late fix doesn't mean re-running the whole suite just to make the report tell the truth.

The correction is recorded rather than quietly applied. Each change to a manual result keeps its new status, any message you leave, and who made it, so the run shows both where it landed and how it got there — which matters when the report is the evidence behind a go/no-go call.

Pause a Manual Run

Manual testing rarely runs start to finish in one sitting. You can now put a manual run on hold from its ⋯ menu — the run turns to a paused state, its elapsed time is banked so your duration stays honest, and every result you've already marked keeps its status. Nothing is reset, and nothing needs re-doing when you come back.

Unassigned Filter in Manual Runs

During a manual run you can now filter down to the results nobody has picked up. A grey Unassigned avatar sits beside the assignee avatars on the execution screen and the report page — click it to see only the results with no one assigned, click again to clear. It's the missing half of assignee filtering: you could already see one person's workload, and now you can see what's still waiting to be handed out.

Test Distribution Strategies

A run's Auto-Assign setting now offers four ways to distribute tests among testers. Alongside None and Prefer test assignee, the two automatic options are now distinct: Evenly splits the tests into equal contiguous blocks, one per team member, while Randomly assigns each test independently to a randomly picked member. Choose evenly when you want each tester working through a coherent section of the suite, and randomly when you want the work scattered — useful for spreading unfamiliar areas across the team.

Note: if you have runs configured with the previous "Randomly" option, their behaviour has changed. What used to be called Randomly assigned tests in equal contiguous blocks — that behaviour is now named Evenly, under a name that actually describes it, and Randomly does what its name says. Any run still set to Randomly will now scatter assignments rather than split them into blocks.

Select Tests by Default on the New Run Screen

Starting a run now begins where most runs actually begin — with choosing what to run. Select tests is the default option on the New Run screen, so the tests tree is in front of you the moment the screen opens, with no extra click to get there.

From there you can pick exactly the tests you want straight from the tree, following your existing suite and folder structure. The other run options are still one click away for the times you need them.

Test Management

Rich Editor for Bulk Suite Editing

Editing a whole suite at once no longer means writing markdown. Bulk edit now opens with two tabs — the familiar Markdown editor, and a Rich Editor that gives you a formatted, block-based view of the same content. Write a test's description with real headings, lists and tables in front of you rather than syntax, and switch tabs whenever you'd rather work in markdown directly.

Drag and Drop Enhancements

Alongside dragging a single test or suite, you can move a whole selection at once: select several rows, drag any one of them, and the group travels together with its relative order intact.

You can also copy instead of move. Hold Alt — Option on a Mac — as you drop, and the originals stay where they are while copies land at the drop point. It works for single items and multi-selections alike, which makes duplicating a suite of tests into another part of the tree a single gesture rather than a create-then-move sequence.

Checkboxes in the Tests Tree

Selecting several tests no longer starts with a mode switch. The checkbox icon at the top of the Tests page has been removed, and checkboxes now sit directly in the tree — tick what you want and act on it, without first turning multi-selection on. Everything you could do with a selection before still works the same way.

It's a small change that removes a step people had to learn was there. It pairs with multi-item drag: select rows in the tree and drag the group in one continuous motion, rather than switching modes, selecting, and switching back.

Undetach Tests

A bad import can mark a whole suite of automated tests as Detached — they were imported before, but the latest import didn't find them. Until now, bringing them back meant working through them one at a time. Filter the Tests page by state Detached and a banner appears with an Undetach tests action that clears the state from all of them at once.

The action is deliberately project-wide: it clears every detached test in the project, not only the ones matching what you're currently filtered to. That's what makes it useful after a failed or misconfigured import, when the detached tests are scattered across suites — but it's worth knowing before you confirm.

When you want something narrower, a suite's menu offers Undetach whenever it contains detached tests, and any individual detached test can be undetached from its own menu.

Imports Moved to the Tests Page

Importing tests now lives where your tests do. Imports has moved out of the left sidebar and into the additional menu on the Tests page, the main page of your project — so you reach it in the same place you're already working with your test tree, rather than navigating away to a separate sidebar entry.

The change also keeps the left sidebar focused on moving between the main areas of a project, with page-level actions like imports sitting on the page they belong to.

Analytics and Dashboards

Run Statistics with a Trend Chart

The company Dashboard's run statistics widget now comes in a second variant that puts a stacked area chart above the table. Where the table gives you the detail of each run — test counts, the manual and automated split, success rate and defect information — the chart gives you the shape of it: whether pass and fail rates are trending the right way across the period you're looking at, without reading down a column of numbers to find out.

Add it from the dashboard's widget picker and choose the EnhancedRunStats variant of the run statistics query. When the dashboard covers more than one project, a project filter in the widget header narrows both the chart and the table together, so you can isolate one team's runs without rebuilding the widget.

Filtering by Who Executed a Test

You can now filter on the person who actually ran a test, rather than the person it was assigned to. executed_by in TQL matches the executor, and the same information is available across the product: an Executed By filter on every test-run dashboard widget, executor filtering on the Analytics landing page, and executed_by on API v2. Assignment and execution frequently diverge — a test handed to one tester and picked up by another was previously indistinguishable — and now you can ask either question.

One piece of behaviour worth knowing when you combine conditions: executed_by ANDed with executed_at applies both to the same result. executed_by == 'ann@example.com' AND executed_at > '2026-01-01' returns tests Ann executed within that window — not tests Ann has ever executed that someone happened to run recently. OR and NOT keep each condition independent.