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

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:

1. Iterates through the issue's changelog
2. Finds the entry where status changed to "In Testing"
3. Gets the timestamp of that transition
4. Finds who was the assignee at that point in time
5. 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! 

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:

1. 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.

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

Your task:

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

2. Extract status and assignee information from each changelog entry.

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

4. 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.

5. 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".

6. 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.

7. Format the output as a clear, readable table.

Here's what my configuration screen looks like:

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:

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

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

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.

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

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:

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

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

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:

1. 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".
2. Pick a date/time within that interval.
3. Run an Issue Snapshot for that date/time.
4. 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.

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

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.