SonarQube & Static Analysis Vocabulary — Code Quality Exercises

1 / 5

A developer pushes code and receives a CI notification: "Quality gate failed. New code coverage is 61%, below the required 80%. 3 new code smells, 1 new bug, 0 new vulnerabilities." What does each term mean, and what must the developer do before merging?

SonarQube classifies all findings into three issue types, and the quality gate is an automated policy that blocks delivery when thresholds are exceeded.

The three SonarQube issue types:

Issue type	Quality dimension	Example
Bug	Reliability — code that will misbehave	Null pointer dereference, resource leak
Vulnerability	Security — code that can be exploited	SQL injection, hardcoded credential
Code smell	Maintainability — code that works but is hard to change	Overly complex function, duplicated code

Quality gate — how it works:
A quality gate is a set of conditions configured by the team (e.g. "new coverage ≥ 80%, zero new bugs, zero new vulnerabilities"). If any condition is not met, the gate fails and the PR is blocked until resolved.

Responding to a quality gate failure:
① Check the SonarQube report — prioritise fixing bugs and vulnerabilities first (reliability and security)
② Write tests to reach the coverage threshold on new code
③ For code smells: either fix them or raise a technical debt item (some teams allow justified exceptions)
④ Re-push to trigger a new scan — the gate will pass when all conditions are met

Key vocabulary:
• Quality gate — an automated pass/fail policy that blocks merging when SonarQube thresholds are violated
• Quality gate failed — one or more conditions are not met; merge is blocked
• Bug — a reliability issue: code that will behave incorrectly at runtime
• Vulnerability — a security issue: code that could be exploited
• Code smell — a maintainability issue: code that works but makes future changes harder

2 / 5

During a code review the tech lead says: "SonarQube is flagging this as a security hotspot rather than a vulnerability. That means it's not confirmed — we need to review and triage it before the gate will pass." What is the difference between a security hotspot and a vulnerability in SonarQube?

3 / 5

A team lead presents the SonarQube dashboard to the sprint review: "Our debt ratio is 12.4%. That means if you were to remediate all the technical debt in the codebase, it would take 12.4% as long as it took to write the code in the first place. We want to drive this below 5% by end of quarter." What does debt ratio measure, and how is it calculated?

The SonarQube debt ratio (part of the SQALE methodology) provides a codebase-wide maintainability health score by expressing technical debt as a proportion of development investment.

How debt ratio is calculated:
Debt Ratio = (Remediation Cost of All Issues) / (Development Cost Estimate) × 100%

• Remediation cost: SonarQube assigns a fixed remediation time to each code smell type (e.g. "extract this method = 20 minutes") and sums across all issues
• Development cost estimate: typically estimated as (total lines of code × 30 minutes per line of new code) — a rough industry baseline

SQALE maintainability rating:

Rating	Debt ratio
A	≤ 5%
B	6–10%
C	11–20%
D	21–50%
E	> 50%

Reporting language:
• "We're currently rated C on maintainability — our goal is to reach A (below 5%) by Q4."
• "The debt ratio has grown from 8% to 12% this quarter — we need to address it before it compounds."
• "Remediating the top 20% of debt issues by cost would cut our debt ratio roughly in half."

Key vocabulary:
• Debt ratio — the ratio of estimated remediation cost to estimated development cost, expressed as a percentage
• SQALE rating — SonarQube's A–E maintainability grade derived from debt ratio
• Remediation cost — the estimated developer time required to fix an issue
• Drive below 5% — reach the SQALE "A" rating (elite maintainability band)

4 / 5

A backend developer opens a SonarQube finding and reads: "This is a blocker severity bug — NullPointerException likely at runtime. The remediation effort is estimated at 30 minutes." What do severity levels mean in SonarQube, and how should the developer prioritise this finding?

SonarQube severity levels provide a ranked prioritisation framework that tells developers how urgently each finding must be addressed.

SonarQube severity levels (highest to lowest):

Severity	Meaning	Action
Blocker	Will crash / corrupt data / break security	Fix before any deployment
Critical	High probability of runtime error or security breach	Fix in current sprint
Major	Could lead to unexpected behaviour; significant debt	Fix or schedule for backlog
Minor	Small debt; unlikely to cause issues	Fix opportunistically
Info	Style or observation; no risk	Consider or ignore

About remediation effort estimates:
SonarQube estimates how long it takes to fix each issue type based on typical developer effort. "30 minutes" is an estimate, not a guarantee — use it for backlog sizing and sprint planning, not as a precise commitment.

Quality gate interaction:
Most team quality gates are configured to fail on any new blocker or critical issue; lower severities may be allowed to accumulate up to a threshold.

Developer communication language:
• "We have a blocker on the null-check — this is a must-fix before we can merge."
• "The critical and blocker findings should be addressed this sprint; we can schedule the majors for the backlog."
• "SonarQube estimates 30 minutes of remediation — I'll fix this now and re-scan."

Key vocabulary:
• Severity — the ranked urgency and impact level of a SonarQube finding
• Blocker — the highest SonarQube severity; must be fixed before any deployment
• Remediation effort — SonarQube's estimated developer time to fix a given issue
• Re-scan — triggering a new SonarQube analysis after fixing issues to confirm the quality gate now passes

5 / 5

A platform engineer presents the quarterly SonarQube summary to the CTO: "We've reduced our technical debt from 45 days to 18 days of remediation effort. Our quality gate pass rate on new PRs is now 94%. The remaining debt is concentrated in the legacy payment module — we're recommending a focused remediation sprint before the v3.0 release." What does "days of remediation effort" mean, and why is isolating the legacy module important?