nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to report on the assignee of a Jira story while it was in "In Testing" status, using history

Svetlana Mandrosova_83e4gr

I need to be able to pull the report to see who was assigned to a story when a story was In Testing status. The goal: I need to know, who executed the Testing. I cannot rely on the Assignee field, as it gives me the name of the current person assignee to a story. In many cases it would be the person who moved the story from AP status to RTR or Closed. That is why I need a way to query the history

Accepted answers

All comments

Cristian Quiroz

Hi @Svetlana Mandrosova !

Unfortunately, there's no native way in JQL to query "who was the assignee WHEN the status was X", status WAS and assignee WAS exist independently but you can't combine them temporally.

Workaround for the future (Automation)

You can capture the tester automatically going forward with a simple rule:

Trigger: Issue transitioned → status = "In Testing"
Action: Edit issue → set a custom field (e.g., "Tester") = {{assignee.displayName}}

This will store the person who was assigned at the moment the issue entered "In Testing". From there, you can filter/report on that field normally.

Limitation

This only works prospectively (for new transitions going forward). For historical data, Automation can't help, even if you call the REST API via "Send web request" to get the changelog, the JSON response requires correlating timestamps between status changes and assignee changes, and Automation smart values don't support that kind of conditional logic over nested arrays.

For historical data: ScriptRunner

If you have ScriptRunner installed, this becomes much easier. You can write a Groovy script that:

Iterates through the issue's changelog
Finds the entry where status changed to "In Testing"
Gets the timestamp of that transition
Finds who was the assignee at that point in time
Optionally populates a custom field with that value (for bulk backfill)

This gives you full control to backfill the historical data and also run it as a scheduled job or listener going forward.

Hope that helps!

Tomislav Tobijas

Hi @Svetlana Mandrosova ,

What you could maybe explore and play around with is this: Build custom Forge apps in Rovo Studio - no code required! 👀

Basically, see what Rovo suggests and build around it.

I know some of our clients use Marketplace apps for reports like this one, but if you only need this specific report, you could vibecode it and see what comes out.

If you do manage to get it to work, I'd appreciate it if you could share what it looks like

Cheers,
Tobi

Ben Spillane

Hi @Svetlana Mandrosova ,

In addition to the the two viable solutions suggested so far, I'd like to offer you a third.

This solution requires your Jira instance to have access to Rovo capabilities and the ability to create new agents via studio.atlassian.net. If you're not familiar with these tools or whether you have access, please reach out to your Jira or Org administrator(s).

Your use case is actually a great idea for a custom agent.

The Status Assignee Reporter Agent

(I'll skip the low level detail on configuring agents as there's heaps of fantastic support documentation available.)

Here's the instructional text you could provide when setting up an agent to report on status + assignee mappings:

You are a helpful assistant that analyzes Jira changelog data and creates organized status-to-assignee tables.

You can work in two ways:

Jira issue key provided — If the user provides a Jira issue key (e.g. PROJ-123), use the 'Get changelog' tool to fetch the changelog for that issue, then proceed to generate the table.

Raw changelog data provided — If the user pastes changelog JSON directly, parse it and generate the table.

Your task:

Obtain the changelog data (by fetching it or parsing what was provided).

Extract status and assignee information from each changelog entry.

Create a table with columns: Status | Assignee | From | To | Duration.

Follow these rules:

One row per unique Status + Assignee combination.

Sort rows by From date descending (most recent first).

If a status had multiple assignees, each gets its own row, also sorted by From date descending.

Use the exact status and assignee names from the changelog.

Use "Unassigned" if no assignee is recorded.

Format the From and To columns using the original date and time from the changelog (e.g. "12 Aug 2025, 14:32"). For the To column, if the status is still current, display "Now".

The Duration column should show a friendly human-readable duration for how long the status was (or has been) held, calculated as the difference between From and To (e.g. "4 days", "2 hours", "3 months"). If the status is still current, calculate the duration from the From date to now.

Format the output as a clear, readable table.

Here's what my configuration screen looks like:

Screenshot 2026-08-16 at 07.21.42.png

A couple of notes:

I've added skills that the agent requires to retrieve the change log information.
I've added additional skills for the agent to access the Jira work item details and create comments, should you wish your agent to write the response as a comment.
No knowledge has been added to this agent as it's role and responsibility doesn't need to extend beyond the narrow scope we've provided. e.g. Change log interpretation.

What does the agent return?

Based on the above instructions here's an example of what my agent returns:

Screenshot 2026-08-16 at 07.27.49.png

Being an agent, you're also able to query for more specific scenarios, for example:

Screenshot 2026-08-16 at 07.29.49.png

I hope this answer is helpful, or at least demonstrates some useful capabilities you may or may not have already been familiar with.

Regards,

Ben

Andrey - Guenov Labs

Hi Svetlana,

One thing worth adding to the answers above: there is a native, retroactive way to get at this, as long as you can name the likely testers.

JQL's CHANGED operator takes a BY predicate, and it reads the changelog:

project = ABC AND status CHANGED FROM "In Testing" BY "sam@example.com"

That gives you every story Sam moved out of In Testing — which, in most workflows, is the person who actually finished the testing. Run it once per tester (or BY (sam, alex, jo), which accepts a list) and you have your historical answer with no app and no script. You can bound it with DURING ("2026/01/01", "2026/06/30") if you only need a period.

That's usually a better proxy than "who was assigned at the time", for exactly the reason you gave — the assignee often lags the real worker.

For going forward, I'd tweak the Automation rule suggested above. Instead of capturing the assignee when the issue enters In Testing, capture the actor when it leaves:

Trigger: Work item transitioned → from "In Testing"
Action: Edit work item → set custom field "Tested by" = {{initiator.displayName}}

{{initiator}} is whoever performed the transition, so this records the person who did the testing rather than whoever happened to hold the ticket. If your team sometimes hands off mid-test, capture both fields — {{assignee.displayName}} on entry and {{initiator.displayName}} on exit — and compare.

If you do need the full historical reconstruction (assignee-at-a-point-in-time for every issue, not just per-tester), you don't need ScriptRunner for it. The changelog is available over the plain REST API:

GET /rest/api/3/issue/{issueKey}/changelog

or in bulk with POST /rest/api/3/search/jql and expand=changelog. Then walk each issue's history: find the entry where field == "status" and toString == "In Testing", note its created timestamp, and take the most recent field == "assignee" change before that timestamp — its toString is who was assigned at that moment. Twenty lines of Python.

One gotcha that will bite you there: the changelog only records changes, so if an issue's assignee was set at creation and never changed, there is no assignee entry at all. In that case the value in effect is the fromString of the first assignee change (or Unassigned if there never was one). Miss that and a chunk of your older issues come back blank.

I'd start with the CHANGED ... BY query — it's five minutes and may be all you need.

Petru Simion [Simitech Ltd.]

Hi @Svetlana Mandrosova ,

Yes, this can be determined from Jira's historical data.

As mentioned above, you can extract the changelog through the REST API, or manually inspect the history of an individual work item. The basic idea is to determine when the work item entered "In Testing" and when it left "In Testing", and then determine which Assignee value was in effect during that interval.

The difficulty is that doing this manually across many work items can become quite time-consuming, and reconstructing the values programmatically requires correlating the different changes in the changelog.

Another option is Issue History & Snapshots Reporter for Jira. The workflow for your particular use case would be:

Run the Issue History report and filter the history by the Status field. This makes it easy to identify when the work item was moved into "In Testing" and when it was moved out of "In Testing".
Pick a date/time within that interval.
Run an Issue Snapshot for that date/time.
The snapshot reconstructs the values of the work item's fields as they existed at that point in time, including Assignee.

So rather than trying to correlate the Status and Assignee changelog entries yourself, you can first establish the "In Testing" time interval and then ask for the state of the work item at a point inside that interval.

Screenshot from 2026-08-16 22-33-23.png

This becomes particularly useful when you need to do this for more than one work item. Instead of manually opening the history of each individual Jira work item and reconstructing its state, you can run the history and snapshot reports across a set of work items and see the historical information together in a report.

Disclosure: I am part of the team that released Issue History & Snapshots Reporter for Jira.

Regards,

Petru

Rustem Shiriiazdanov _Actonic_

@Ben Spillane that's one splendid usage for ROVO omg! So cool.

Birkan Yildiz _OBSS_

Hey @Svetlana Mandrosova ,

First of all, welcome to the Atlassian Community!

If you are open to using a marketplace app, you can easily build this report using Historian - History Explorer for Jira:

JQL Scope: Run a JQL query in the app to find your target issues (e.g., project = MYPROJECT AND status WAS "In Testing").
Select Your Fields: Use the field selector to include only the Status and Assignee fields. This filters out any other clutter from your changelog.
Analyze Chronologically: In the Work Item Based View, each issue is organized in its own row. Expanding an issue shows the exact timeline of changes. You can look at the timestamp when the status became "In Testing" and instantly see who was assigned to the story at that exact time.

Export to Excel: You can instantly export this audit-ready table to XLSX or CSV.

This allows you to quickly filter and share a clean list of who executed the testing for each story. I hope this helps you track down your testing execution metrics smoothly!

Full disclosure: I am part of the OBSS team, the creators of Historian.

Best,
Birkan

Rustem Shiriiazdanov _Actonic_

Hi @Svetlana Mandrosova

Unfortuantely, Jira keeps assignee changes and status changes as two independent streams in the issue changelog, and the bad thing is that nothing correlates them for you. That's why no JQL answers this. You either capture the value at the moment it matters (going forward), or reconstruct it from the changelog (for the past). Both are worth doing.

JQL does have history operators, ofc, f.i. status CHANGED FROM "In Testing", assignee WAS "x" DURING (...), etc. But in assignee WAS ... DURING (...) the window is a date range, while the window you actually care about is "while this particular issue was In Testing"w hich is totally different for every issue.

Combining assignee WAS X and status CHANGED TO "In Testing" doesn't solve it either. Jira evaluates those histories independently, so it can return an issue where both happened, but never at the same time.

The status CHANGED FROM "In Testing" BY user approach @Andrey - Guenov Labs mentioned is probably the closest native approximation. Just keep in mind that it tells you who transitioned the issue, not who was assigned to it. In some teams that's effectively the tester; in others, especially where leads or automation move issues, it can be completely different.

For new issues, I'd avoid reconstructing this at all. Add a "Tested by" user field and populate it with Automation when the issue leaves In Testing. Then it's just normal Jira data and you can use it anywhere.

For historical issues, you have to reconstruct it from the changelog: take the periods where the issue was In Testing and match them against the assignee history.

If you need to do that across a lot of issues and up for 3rd party apps, then me, as a vendor representative can recommend Report Builder https://marketplace.atlassian.com/apps/1216997/report-builder-custom-charts-dashboards-for-jira?hosting=cloud&tab=overview as it can handle your case handle it with a Scripted Report.

The script can correlate the two timelines and give you something like:

<span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Screenshot 2026-08-17 131119.png" style="width: 999px;"><img src="https://us.v-cdn.net/6038660/uploads/images/440322iB90C324FE696B82F/Screenshot%202026-08-17%20131119.png" role="button" title="Screenshot 2026-08-17 131119.png" alt="Screenshot 2026-08-17 131119.png"></span>

But I also absolutely love response from @Ben Spillane - using ROVO capabilities for your use cse seems to be elegant and fast solution.

Natalia_Kovalchuk_SaaSJet_

Hi @Svetlana Mandrosova !

Yes, this is the kind of case where you need historical Assignee and Status data, not just the current Assignee value.

With Issue History for Jira (Work Item History) by SaaSJet, you can create a report that shows who was assigned to a story when it was in a specific status.

For example, in our workflow, we use QA Review instead of In Testing. In the app, you can:

select the space, sprint, or date range you need,
apply the Status transition filter and choose In Testing (in our case, it's QA Review) as the status you want to look at,
add the Assignee column to the report.

This allows you to see the assignee linked to the work item during that historical status, not just the person currently assigned to it.

You can also export the report to Excel or CSV if you need to analyze or share the data outside of Jira.

You can check Issue History for Jira (Work Item History) on the Atlassian Marketplace if you want an easier way to query and report on this historical data.

Fatma Uzundemir from The Starware

Hi @Svetlana Mandrosova ,

Welcome to the Atlassian Community!

There’s no native Jira feature that provides this directly. Jira records status transitions in the issue history, but it doesn’t expose information such as who moved the issue to a specific status or when it reached that status as a field that can be displayed or queried directly.

If you’re open to using a third-party app, our Status Update Fields feature can handle this use case.

You can add a field and select the status you want to track. The field can then show:

User — who moved the issue into that status
Date — when the issue entered that status
Both — user and date together

The values are derived automatically from the issue’s change history, so there’s nothing to manually maintain. When you select a status, the field resolves the most recent transition into that status. This also works for issues that have been reopened or have gone through the same status multiple times, as it reports the latest transition rather than an outdated one.

Issue creation is also treated as the first status transition, so the initial status is covered even though Jira doesn’t create a history entry for it.

For your use case, you can configure the field to track the In Testing status and view the user who moved the story into that status. This allows you to determine who performed the testing without relying on the current Assignee field.

history update -hero.png

history update -2.png

🍀 If you’re looking for a plug-and-play solution that saves you from the "formula headache," feel free to explore the Atlassian Marketplace link I’ve provided or reach out to me for more details. 🍀

Disclaimer: I work for the vendor who developed this application.

Melika-Everview

Hi Svetlana! there's a lot of good advice above, so let me just pull out the one native, retroactive answer that needs no app and might be all you need.

Jira stores status changes and assignee changes as two separate streams and never links them, which is exactly why no plain JQL can ask "who was assigned while it was In Testing." But there's a native operator that gets close:

project = ABC AND status CHANGED FROM "In Testing" BY "sam@example.com"

That returns every story a given person moved out of In Testing — which, in most workflows, is the person who actually finished the testing. Run it once per likely tester, or BY (sam, alex, jo) for a list, and bound it with DURING (...) if you only need a period. Five minutes, no app, no script.

The honest caveat: it tells you who transitioned the issue, not who was assigned — those differ on teams where leads or automation move tickets. If that's your case, the changelog is the only fully accurate source, and you'd reconstruct it by matching each "In Testing" interval against the assignee history.

Genuinely curious, and it changes which route is worth the effort: do you need this live — to catch it as testing happens — or is a report after the fact enough for what you're doing?

Ivan Manolov _Appfire_

Hello @Svetlana Mandrosova,

Reconstructing this from the changelog keeps coming up as the accurate but painful route, so here is what it actually involves if you want to do it once without an app.

Jira exposes the full change history per work item at:

GET /rest/api/3/issue/{issueIdOrKey}/changelog

It returns a paginated list sorted oldest first, so use startAt and maxResults to page through long-lived stories. Every entry carries a created timestamp and an items array, where each item has field, fromString and toString.

From there:

Keep the items where field is status and build the intervals in which the status was "In Testing". Each transition into it opens an interval, the next status change closes it, and an interval with no close is still running.
Keep the items where field is assignee and build a timeline of who held the item and from when. The original assignee is not a change entry, so take it from the fromString of the earliest assignee change.
For each "In Testing" interval, read the assignee in effect at its start. If the assignee changed mid-testing, the one with the longest overlap is usually the better answer than the first.

One thing worth flagging on the JQL side: status CHANGED FROM "In Testing" BY (...) and assignee WAS ... DURING (...) are evaluated as independent histories, so combining them in one query can return a story where both happened, but at different times.

Best,

Ivan

Ivan Manolov _Appfire_

Following up on my earlier answer, @Svetlana Mandrosova: if you'd rather not reconstruct the changelog yourself and you're open to solutions from the Atlassian Marketplace, the app my team and I work on, JXL for Jira, has a column type built for exactly this correlation.

JXL is a spreadsheet/table view for your Jira data, and among its history columns there is Time in status with assignee. You configure it with a status ("In Testing") and one or more users, and it reports how long each story spent in that status while assigned to those users, retroactively from the existing history. A non-zero value means that person held the story during testing, and the number tells you for how long.

Because it's a normal column, you get it for every story in the sheet at once, and you can sort, filter, group, or export the result.

Time in status with assignee column in JXL

Two caveats: you configure the users you want to measure rather than getting a single "who was it" cell, and history columns read a lot of data from Jira, so sheets using them load slower than plain field columns.

All the best,

Ivan

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud