Code Quality (SonarQube)

Coding conventions and standards (owned by the Architect/Dev Lead) set the bar; SonarQube measures whether we clear it. Every change is scanned, and because the results are concrete numbers, we drive them in the right direction over time.

How we scan - developer + AI, paired

Code is scanned twice, by two complementary reviewers, before it can merge:

flowchart LR
    DEV[Developer writes code] --> AIS[AI agent reviews & pre-scans]
    AIS --> PR[Pull Request]
    PR --> SQ[SonarQube scan in CI]
    SQ --> GATE{Quality gate pass?}
    GATE -->|fail| FIX[Fix issues] --> PR
    GATE -->|pass| QE[Quality Engineer review] --> MERGE([Merge])

The AI agent catches issues at authoring time; SonarQube enforces the objective gate in CI; the Quality Engineer owns the human judgment. This is the augmented-review pattern applied to code quality - see also Integration & Governance.

The quality gate

A pull request must pass the SonarQube quality gate to merge. The gate is a set of measurable conditions:

Factor	Standard	Why it matters
Unit test coverage	≥ 75%	Confidence that behavior is verified; the project baseline.
Code complexity	Within agreed cyclomatic/cognitive limits	Lower complexity = easier to read, test, and change safely.
Duplications	Below the agreed threshold (e.g. < 3%)	Duplicated code multiplies bugs and maintenance cost.
Blocker issues	0	Blockers are defects that will break in production - none may ship.
Security issues	0 new vulnerabilities / unreviewed hotspots	Security defects are non-negotiable; scanned every build.
Reliability & maintainability	Rating at or above target	Aggregate health of bugs and code smells.

Coverage standard

75% unit-test coverage is the EmeSoft standard. Coverage is necessary but not sufficient - we also review that tests assert meaningful behavior, since AI-generated tests can pass while checking nothing (see Problems & Workarounds). The other thresholds (complexity, duplication, ratings) are set in the SonarQube project profile and reviewed periodically.

What “measure → improve” looks like here

Every factor is a number, so every factor is improvable. We track the gate results sprint over sprint and act on the trend:

xychart-beta
    title "Unit test coverage trend (%) vs 75% standard"
    x-axis [S1, S2, S3, S4, S5, S6]
    y-axis "Coverage %" 0 --> 100
    line [62, 66, 71, 74, 77, 80]
    bar [62, 66, 71, 74, 77, 80]

Typical improvement actions, decided at the Retrospective:

• Coverage below 75% → add tests to the weakest modules first; block new untested code via the gate on new code.
• Rising complexity → targeted refactoring; AI-assisted extraction of methods/classes.
• Duplication creeping up → consolidate shared logic; flag in AI review.
• Recurring security findings → fix the pattern, not just the instance; tighten standards.

Why both humans and AI scan

Reviewer	Strength	Limit
Developer	Intent, domain context	Blind spots in their own code
AI agent	Tireless, consistent, broad coverage	Misses domain nuance; can be confidently wrong
SonarQube	Objective, repeatable measurement	Measures rules, not whether the solution is right
Quality Engineer	Final judgment & accountability	Time - which is why the first three exist

The combination is deliberately layered so each catches what the others miss, while a human stays accountable for the merge.