In this thread already asked for the option of having multiple Software Qualities resp. multiple Severities per rule.
It was as side-note in this thread. So, here a separate thread just for this feature of the MQR (Mutli Quality Rule) in the 2025 versions.
MQR mode is intended to configure different severities for different software qualities, correct? So far I did not find any rule which has multiple software qualities assigned. How to identify them?
[…]
I understand, that you created the idea to have multiple qualities per rule. The UI allows to select different severity by “quality”. But, I did not find any rule where this feature is used.
Further I do not have an idea how I should think about or even more how to use it.
So far, I did not find relevant information in the documentation. Maybe I missed it there.
I’m not sure what your question is! Are you just looking for an example rule where multilpe software qualities are used? I can find several right away on our internal instance.
Thank for the examples. This is one part of my question.
The second part is to understand how to work with them, how to interpret that such a rule is raised for in the code:
Do I have multiple issues? Why?
Do I have a single issue? What the outcome for the quality gate? Is the highest severity used for the gate?
Do we get the option to change the relation between rule, sw quality and severity?
Sure, those are all great questions. Let me clarify:
One rule corresponds to one issue, but that issue can affect multiple software qualities.
A typical example that I give is an out-of-bounds memory access, which can be both a bug (it might cause the application to crash or produce unexpected results due to undefined behavior) and a vulnerability (it could allow unauthorized access to sensitive data).
Despite these multiple impacts, it’s fundamentally one issue due to the single root cause: out-of-bounds memory access.
The “Standard Experience” mode only enables us to classify it as either a bug or a vulnerability, whereas MQR Mode lets both be noted.
To answer the last part of your question, yes.
If the QG condition is set to fail when there are any issues of Blocker Severity, then having an issue with Blocker severity in Security but only Minor severity in Reliability will still cause the Quality Gate to fail. A single issue can affect multiple aspects of the Quality Gate.
You can modify the severity level assigned to a specific software quality, but you cannot add additional software quality impacts. For example, if a rule is designated as having a minor impact on reliability but a blocker impact on security, you can adjust the severity levels but cannot add another impact, such as maintainability.
Ok, basically I understood.
I was wondering how your strategy “Clean as you code” fits to this idea. The “clean” quality gate will not accept ANY issue.
In which use case do we need this feature?
The goal of MQR Mode is to more accurately represent the impact an issue has. While at an individual developer-level it might not be super relevant (you’re right – the goal should be to fix the issues on the code you’ve just written, whatever the impact), at an organizational level, understanding the broader impact of issues can lead to better prioritization and resource allocation.
When describing issues we didn’t want to be locked into the more simplistic taxonomy (one issue = one issue type) forever. And, lots of people work well in that workflow, so ultimately we decided to maintain it alongside the new taxonomy.
Currently we do not see a benefit for the MQR mode.
So, a very important question for us is now: What is you future vision for these modes? Will both modes remain active and supported in all editions?
