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

[Svetlana Mandrosova]

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

[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:

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! 

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

[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:

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

[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