User Story Coverage
Install, configure, and run User Story Coverage from first report to published results.
User Story Coverage connects your issue tracker with SeaLights coverage data. It measures coverage by user story, feature, or sprint.
Coverage at the story level gives development and QA a shared, transparent view of quality throughout the release cycle, so teams catch gaps before release instead of after. Watch the 2-minute overview video for the business case behind this feature.
Audience:
Development and QA teams use this together to keep coverage visibility shared across the team, rather than siloed in one role:
DevOps engineers automating test coverage reporting in CI/CD pipelines
QA engineers monitoring test coverage for specific user stories and features
Engineering managers tracking team-level coverage metrics across sprints
Release managers confirming adequate test coverage before production releases
What it does
It helps you:
extract ticket IDs from source control activity
tag code changes in SeaLights
generate coverage reports for stories and work items
push coverage results back to Jira or Azure DevOps
When to use it
Use this section when you want to:
report sprint coverage for completed stories
track coverage for pull requests or merged changes
publish story-level coverage to Jira, Azure DevOps, or Confluence
automate coverage reporting in CI/CD
How it works
The workflow has two phases:
Source tagging — optional when SeaLights auto-tagging is enabled
Reporting — always required to generate and publish coverage results
Key benefits
Quality visibility — insight into coverage at the user story level across every test stage, not just at the build level
Cross-team collaboration — gives development and QA a shared, transparent view of coverage, reducing the risk of undetected defects reaching production
Traceability — direct linkage between user stories and test coverage
Automation — eliminates manual coverage reporting
Flexibility — supports GitHub, GitLab, Bitbucket, and Azure DevOps Git
Multi-format reporting — HTML, Confluence, JSON, and direct issue-tracker updates
If your builds already report git commit data to SeaLights and auto-tagging is enabled, you can skip the manual US_SRC_* tagging scripts.
Choose your path
Core workflow
Use this order for most teams:
Use Installation and first run for the first working setup.
Use Configuration and Deployment patterns for the advanced flows.
By job to be done
Use these entry points when you already know what you need:
Installation and first run — get the first report working quickly
Configuration — define inputs, scope, and publication targets
Deployment patterns — choose a delivery pattern for Jira, Azure DevOps, Confluence, or CI/CD
Security Considerations — secure credentials, access, and automation
CLI Reference — run the exact commands
Advanced
Use this when you need deeper reference or diagnostics.
Last updated
Was this helpful?