Quality Information Coverage is a concept that refers to the degree to which an organization has collected all necessary quality information about a product to make informed decisions regarding quality. It is more comprehensive than individual metrics like code coverage or test coverage. An organization should evaluate whether it has sufficient Quality Information Coverage of all relevant areas of a product before making decisions like release. While a single percentage metric may be difficult, organizations should have conversations around what quality information is available for different areas of a product.

1. Quality Information Coverage - A QI Concept
When I talk about Quality Intelligence [1][2], an important part of the QI concept is transparency
and visibility [3]. Providing the right quality intelligence to the right stakeholders at the right time.
When doing this I find it valuable to talk about “Quality Information Coverage”, a concept which I
am going to expand on in this article.
Code coverage [4] and test coverage [5] are concepts we are all more or less familiar with, even
though we might interpret them slightly differently. We may also know about risk coverage or
requirements coverage [6]. All of the above (and other types of coverage) provide information
about quality in their own way. But what stakeholders need to know is if we have sufficient
quality information (that can be transformed into quality intelligence) for them to make informed
decisions. They need to know if we have good enough quality information coverage.
So what is quality information coverage? It is more than if our requirements have been tested. It
is more than if we have investigated all risks. It is more than all the tests we have performed.

2. Quality Information Coverage is to what degree we have all the necessary information we need
to be able to make informed decisions around the quality of our product.
So how do we use this? Do we set a number we should reach?
“We need 80% or higher Quality Information Coverage!”
This is a complex metric and it may be difficult to put an exact number on it. A number metric
can also unintentionally drive unwanted behaviors. But there are important conversations to be
had around this metric, throughout the development life cycle, and especially before release.
● “Do we have enough quality information of all relevant parts and aspects of the product
to be able to make an informed decision about if we are ready for release or not?”
● “Do we have enough quality information of all relevant parts and aspects of the product
to be able to say something about the accuracy of our estimations for when we are going
to deliver?”
● “Do we have enough quality information of all the relevant parts and aspects of the
product to be able to reflect on and improve our ways of working? Are we developing
high quality software efficiently?”
● “Do we have enough quality information of all the relevant parts and aspects of the
product to understand if the tools and environments we are using are good enough?”

3. The goal of talking about Quality Information Coverage is to spark the right conversations
around if we have enough quality information for whatever we are discussing or deciding.
It could be represented as simply as this:
Product Area Quality Information Coverage
Area 1
Area 2
Area 3
Area 4
Or it could be something more complicated. It all depends on the context, and what you are
trying to get out of it.
As long as the conversations happen you are getting somewhere.
Johan Hoberg

4. References
[1] What is QI
https://www.slideshare.net/JohanHoberg/what-is-qi
[2] QI, not QA
https://www.slideshare.net/JohanHoberg/qi-not-qa-68042026
[3] Quality Intelligence: Transparency & Visibility
https://www.slideshare.net/JohanHoberg/quality-intelligence-transparency-visibility
[4] What is code coverage?
https://www.atlassian.com/continuous-delivery/software-testing/code-coverage
[5] Test coverage
https://www.softwaretestinghelp.com/test-coverage/
[6] 100% Coverage is Possible
https://www.developsense.com/blog/2016/04/100-coverage-is-possible/
[7] Product Risk Analysis
https://www.tmap.net/building-blocks/product-risk-analysis-pra