Change advisory board dashboard cannot show test execution status for linked stories

ALM Atlassian Jira Software
, , , , , , , ,
1

Our CAB wants a single dashboard showing change requests with their implementation stories and current test status. We’ve linked Stories and Bugs to Change Request tickets using the standard “relates to” link type, but the CAB dashboard gadgets can’t pull test execution data from those linked issues.

The problem is our test executions are tracked on the Story level (we update a custom “Test Status” field), but Change Requests don’t automatically reflect this. The CAB needs to see at a glance whether all linked work has passed testing before approving production deployment.


GET /rest/api/2/issue/CR-1234?fields=issuelinks
// Returns linked stories but no test status
// Need aggregated test state on CR itself

We’ve tried Filter Results gadgets with JQL but can’t aggregate test status across multiple linked issues. Are we supposed to manually update the CR, or is there an automation pattern that rolls up test execution status from implementation issues to the parent Change Request?

2

One gotcha: if you have dozens of Stories per CR, the automation can be slow. We ended up using a scheduled automation that runs every 30 minutes instead of real-time triggers. It queries all open CRs, checks their linked issues, and batch-updates the readiness field. Much more efficient for high-volume environments.

3

The standard issue links don’t propagate field values automatically. You’ll need either a custom field on the CR that gets updated via automation, or a scripted field that queries linked issues in real-time. For CAB dashboards we typically use a “Deployment Readiness” field on the CR itself.

Create an automation rule: when Test Status changes on a Story linked to a CR, the rule calculates if all linked Stories have “Passed” status, then updates the CR’s Deployment Readiness field to “Ready” or “Blocked”. Use the branch rule to iterate through all linked issues.

4

Thanks, that makes sense. So the CR needs its own aggregated field. Do you recommend a single-select like “Ready/Blocked/In Progress”, or something more detailed? Also, should the automation run on every Story update, or only when Test Status specifically changes?

5

The scheduled automation catches regressions on the next run. We also have a separate real-time rule: if any linked Story’s Test Status changes TO “Failed” or “Blocked”, immediately set the CR’s readiness to “Blocked” and post a comment tagging the CAB lead. That way critical failures don’t wait for the next batch cycle.

6

Scheduled makes sense for performance. How do you handle the case where a Story’s test status gets downgraded after the CR was already marked Ready? Do you have alerts or does the next scheduled run catch it automatically?

7

Here’s the complete solution pattern we’ve implemented across multiple CAB workflows:

1. Change Request Linking Model: Use a dedicated link type “implements” from Story/Bug → CR (not generic “relates to”). This makes JQL filtering cleaner and automation scoping precise.

2. Test Execution Association: Maintain Test Status field on Stories (values: Not Started, In Progress, Passed, Failed, Blocked). This field must be mandatory when Story moves to Testing or Done status to ensure data quality.

3. Automation-Based Status Roll-Up: Create a custom single-select field on CR: “Test Readiness” (values: Not Started, In Progress, Ready, Blocked).


// Scheduled automation (every 30 min):
FOR each CR in status "Pending Approval":
  linked_stories = CR.issuelinks[type="implements"]
  IF any story.testStatus == "Failed" OR "Blocked":
    CR.testReadiness = "Blocked"
  ELSE IF all stories.testStatus == "Passed":
    CR.testReadiness = "Ready"

Add a real-time rule: when any Story’s Test Status → Failed, immediately update linked CR to “Blocked” and notify CAB lead.

4. Dashboard Gadgets Configuration: Use Filter Results gadget with JQL: project = CAB AND status = "Pending Approval" ORDER BY testReadiness ASC. Configure columns to show: CR Key, Summary, Test Readiness, Linked Issues Count. Add a Two Dimensional Filter Statistics gadget showing Test Readiness distribution.

5. Process Training: Document the linking standard in your change management procedure. Train teams: every Story/Bug implementing a CR must use “implements” link type and maintain Test Status. Add a dashboard gadget showing CRs with unlinked or untested Stories to catch process violations.

Bonus tip: Create a board for CAB review with columns mapped to Test Readiness values. The CAB can visually swim-lane CRs and quickly approve those in the “Ready” column. We also use color-coded labels (green/yellow/red) for at-a-glance status during meetings.

This pattern has reduced our CAB meeting time by 40% because all test evidence is pre-aggregated and visible in a single dashboard. The key is enforcing the linking discipline and making Test Status a required field.