For Jira Cloud · team-level QA metrics
QA metrics your team can check against the board
Quality metrics for the whole team on one Jira page, from sprint say/do to the test pyramid. Sprint, bug, reopen and coverage numbers open the issues behind them.
01 · Metrics
Every number comes with its formula
++
Test pyramid
How many unit, integration and end-to-end tests your pipelines actually run, next to the Jira work they test. You see straight away when the pyramid turns into a cone.
How we count: test cases per layer from JUnit reports. Sprint history from GitHub Actions; GitLab.com counts in the live view.++
Sprint say / do
How much of what the team committed at sprint start actually got done.
How we count: completed issues from the original plan ÷ issues in the original plan.++
Defect leakage
In which environment bugs are found: dev, stage or prod.
How we count: bugs that reached the last environment ÷ classified bugs; unclassified shown beside.++
Reopen rate
How often done work comes back.
How we count: issues that came back ÷ all counted issues that were in the sprint.++
Epic progress
How far each epic is, plus the epics closed this year.
How we count: done issues ÷ all issues in the epic, live.++
Requirement coverage
Which stories have tests and which have none.
How we count: covered requirements ÷ developed requirements, minus those marked not required.02 · Why you can trust the numbers
Same answer as your board
1
The number matches the Jira board
Done means the Done status category with a resolution set, the same way Jira counts it. Sprint, bug, reopen and coverage numbers open the exact issues.
2
Unknown is shown as Unclassified
A bug with no environment is never counted as zero. It stays visible as Unclassified, with its keys. Closed sprints keep what was known at close.
3
Sprint history is never rewritten
Each closed sprint is saved as a snapshot. If issues move afterwards, the change is marked, not silently merged into the old number.
03 · Who it's for
One page, three roles
ROLE / 01QA lead
Where bugs slip through, which tickets keep reopening and whether the test pyramid holds its shape.
ROLE / 02Scrum master
Say/do for every sprint, and what was added or removed after planning, ready for the retro.
ROLE / 03Manager
Epic progress and the quality trend across sprints, measured for the team, never for individual people.
04 · Connections
Read-only. No source code.
Bugbeak reads test reports from your pipelines to build the test pyramid. It never clones a repository and never reads your code.
GitHub ActionsGitHub App · read-only · workflow runs and JUnit artifacts
GitLab.comread-only access · pipeline test reports
++++
05 · Data & security
- We read
- Jira issues, sprints, epics, their standard fields and history; test reports from your CI.
- We store
- Counts and percentages per sprint, plus the issue keys and summaries behind them.
- We don't store
- Source code, issue descriptions, comments or attachments.
- Where
- In Atlassian Forge storage for your site. Deleted 28 days after uninstall.
No data is sent to AI.
06 · Pricing
Pricing at launch
Billed through Atlassian Marketplace. The price will be published here when the app goes live.