---
title: "Using Coverage to Mitigate Risks"
canonical: "https://docs.getxray.app/space/XRAYCLOUD/976453642/Using%20Coverage%20to%20Mitigate%20Risks"
format: markdown
---
> Macro (rw-ui-expands-macro)
>
> > Macro (rw-expand)
>
> > Macro (toc)
# Introduction
## Why does Coverage Matter?
Aren’t Test results enough if you have all of them passing? Before answering it, stop for a minute and think: what are these Tests really checking? Do they have any relation whatsoever to my planned release deliverables? Do they cover existing features? Do they cover the new features? What about bug fixes?
So, no; Test results are not enough as they, just by themselves, have no connection to the items that your team is working on. 100% Tests passing is better than 90% Test passing; however, it doesn’t tell you anything about whether they test the new and old business requirements, and whether those are ready to be shipped or not.
Coverage is all about understanding: “**are my deliverables, previous and new features, and also bug fixes, covered with Tests and what do they tell me about their quality?**”
Therefore, coverage is about connecting requirements<>Tests to assess quality in a given context (e.g., release, environment), based on the results obtained from those Tests.
Coverage in Xray goes beyond the simple “Is my requirement covered or not?” question; it also takes into account the latest Testing results, and from multiple angles, including release and environment. Xray coverage capabilities are a key enabler to support teams and help them deliver with more confidence based on real-time quality insights.
# Main Benefits
## Avoiding Testing Gaps
Your team can tell you they tested all features. But is that a risk you can live with? Do you and your team have any way to make sure all items have been tested?
With real-time coverage information on your Story work items, or even at the Space level, you can easily depict uncovered items and thus avoid forgetting to test requirements/deliverables, or bug fixes, that could escape unnoticed otherwise.
> ✅ Xray gets you and your Work items covered.
## Ensuring that You Have no Faulty Requirements
With Xray coverage you can assess, in real-time, if your requirements are ok or not based on the latest Testing results. For each Requirement, if one of its Tests fails, then it’s marked as not being ready.
Likewise, Requirements need to be ok in all the different environments, or target browsers/devices, where Tests are run.
## Analyzing all the Angles of Your Product Deliverable
Whenever building products, we may have to support multiple versions at the same time. A feature may be ok on version `1.2.x` but what about on `2.0.y?` Additionally, products can run in different environments, devices, browsers, configurations, etc.. All this requires that a multi-dimensional analysis of quality and release readiness must be performed.
Remember that a given feature can be ok in one very specific context but can be totally buggy in another context. That’s precisely the reason why Xray provides [coverage analysis](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565185) from multiple angles, including version and environment.
## Tracking Hierarchical Coverage Automatically
From small to complex projects, it’s common to have a hierarchy of Requirements to group related items or to represent higher-level requirements, sometimes rolling up to initiatives and themes.
Agile-based teams usually adopt Epics<>Stories, but this scoping of work can be further extended to have a multi-level kind of structure.
With Xray, the coverage you perform on Stories, for example, reflects automatically on the related Epics based on the settings in your Jira Space. Therefore, if all Epic’s user stories are ok, the Epic will also be considered as being covered and ok. In general, coverage status from sub-requirements is automatically reflected on parent requirements, and so on, so forth. This is key to providing release readiness at multiple levels, eventually for different types of stakeholders.
## Visibility that Enables Collaboration
Last but not least, showing real-time coverage status on requirements enables actionability and fosters collaboration. This is imperative to solve problems early in the development lifecycle.
# Questions We Can Answer with Coverage (that We Otherwise Couldn’t)
- *How is the release and its requirements? Have they been tested? Were problems found?*
- *How is this requirement, or set of requirements, on a given environment/device/browser?*
- *Given what was tested for all the different environments, can we release this?*
- *How is my release given what I tested on this **[Test Plan](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565153)**, or during this sprint?*
- *What (requirements) does this Test Plan cover?*
- *What are my latest results for the Tests in this specific version and/or environment?*
- *How are my Epics, Themes, Initiatives, or similar, based on the current quality status/readiness of related Stories and sub-tasks? *
# Mitigating Risks Using Xray Coverage Capabilities
Xray coverage capabilities are a key enabler for managing risk. Besides avoiding Testing gaps and tracking faulty Requirements, as mentioned earlier, with Xray we can:
- Assess coverage depth.
- Avoid releasing “blindly” and make a decision on whether to release or not based on quality insights.
- Analyze quality and readiness of multiple releases at the same time and on multiple environments at once and separately.
## Risk Mitigation Strategies
### Risk Avoidance
Avoid releasing:
- Uncovered Requirements.
- While having critical Requirements with known failures.
- If certain types of Tests (e.g., security) impacting core components have problems.
- If Tests for Requirements are not passing in all relevant environments
### Risk Reduction
Use the [Test Coverage report](https://docs.getxray.app/space/XRAYCLOUD/44565216) to depict coverage depth indicators, such as the number of Tests covering a Requirement, and implement further Tests if needed for relevant Requirements.
### Risk Transference
Use coverage as a way to identify areas with coverage gaps or with problems and use it to decide on transferring risk to a third-party (e.g., by using an external service instead an in-house built component).
### Risk Acceptance
- Track non-critical uncovered Requirements, or partially tested Requirements, to decide whether risk acceptance is a viable option moving forward.
- Use coverage analysis to assess the status of your Requirements based on the results of the most important Tests. It may be acceptable to release despite some small bugs, as long as the most critical scenarios are tested successfully.
# Performing Coverage Analysis in Xray
Coverage can be assessed directly on the work items screens (e.g., on Stories, Epics) or by using [Xray tailored reports](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/338526916) such as the [Test Coverage Report](https://docs.getxray.app/space/XRAYCLOUD/44565216) (Figure 2) or the [Requirement Traceability Report](https://docs.getxray.app/space/XRAYCLOUD/44565208/Requirement+Traceability+Report) (Figure 1).
Besides, it's also available in other places, like on Test Work items, [Tests List Report](https://docs.getxray.app/space/XRAYCLOUD/44565196/Tests+List+Report), and more.
> ℹ️ Check the [Coverage Analysis documentation](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565185) for further details.
# Xray vs Other Test Management Tools vs Excel
| **Feature** | **Excel** | **Other test management tools without advanced coverage capabilities**
(Yes/No/Partial) | **Xray** |
| --- | --- | --- | --- |
| **Establishes explicit linkage between Tests and Requirements**
*(being able to identify relationships and jump from Requirements to Tests and the other way around)* | No
:info: You may identify the covered Requirement in a cell, but the linkage is weak and prone to errors; additionally, it doesn’t provide visibility within Jira | No / partial
:info:* *Some tools may allow you to identify the covered Requirement by putting just the identifier on the Test | Yes |
| **Identify uncovered Requirements (i.e., coverage gaps)**
(identify Requirements without Tests) | No | No | Yes |
| **Assess the coverage status based on Test results**
(OK, NOK, NOTRUN) | No | No | Yes |
| **Automatic coverage status assessment on parent Requirements**
(e.g., status of Epics based on coverage status of their Stories) | No | No | Yes |
| **Coverage analysis per release**
*(assess coverage status based on Test results, for that release, for each Requirement)* | No | No | Yes |
| **Coverage analysis per environment**
*(assess coverage status based on Test results, for that environment, for each Requirement)* | No | No | Yes |
| **Analysis of whole release readiness with a birds-eye perspective on quality**
*(assess whether all release Requirements are covered with Tests and OK, or if some have failures or Testing gaps, for all environments or a specific one)* | No | No | Yes |
| **Ability to consolidate Test results and track their impacts** | No | No / Partial
:info:* Some tools may allow showing the results for the latest build, but they won’t consolidate results or assess the readiness of the Requirements based on these results* | Yes |
# References
- [https://docs.getxray.app/space/XRAYCLOUD/44565185/Coverage+Analysis](https://docs.getxray.app/space/XRAYCLOUD/44565185/Coverage+Analysis)
- [https://docs.getxray.app/space/XRAYCLOUD/44565101/Understanding+the+calculation+of+coverage+status+and+the+status+of+Tests](https://docs.getxray.app/space/XRAYCLOUD/44565101/Understanding+the+calculation+of+coverage+status+and+the+status+of+Tests)
> Macro (rw-ui-expands-macro)
>
> > Macro (rw-expand)
>
> If you have questions or technical issues, please [contact the Support team via the Customer Portal (Jira service management)](https://jira.getxray.app/servicedesk/customer/portal/2/user/login?destination=portal%2F2%2Fcreate%2F28) or [send us a message using the in-app chat](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44577312).