Skip to main content
The coverage map answers two questions every engineering team eventually asks:
  1. Is this feature actually covered by tests?
  2. Where are the gaps we’ll get burned by?
It’s a matrix of coverage areas (the features and surfaces of your app) crossed with test cases, with the most recent result for each pair.

​
Coverage areas

QLane derives coverage areas automatically:
  • From your navigation structure (the agent walks the app and identifies the major sections).
  • From your PR history (recurring file paths and route changes cluster into areas).
  • From linked requirements if you’ve connected an issue tracker or docs source.
You can edit, merge, or split areas from the Coverage tab. Areas are not test cases — they’re the buckets test cases fall into.

​
The matrix view

Each row is a coverage area; each column is a test case. Cells show:
  • Green — the most recent run passed.
  • Red — the most recent run failed.
  • Grey — never run against this area (e.g. a test case was added after the last session).
  • Empty — no test case maps to this area. This is the gap signal.
Filter by level (smoke / sanity / regression) to see what protects the critical path vs. what’s catching subtle regressions.

​
Gap signals

Two flags worth scanning for:
  • Areas with no smoke coverage. A surface that no smoke test touches is one network blip away from being broken without you knowing.
  • Areas with only failing tests. Often the test is wrong; sometimes the feature has been quietly broken for weeks.
The dashboard flags both on the project home page, alongside their owners (if you’ve mapped areas to team members). The Trends view plots pass rate per area over time. Useful for:
  • Release readiness — is the suite stable enough to ship?
  • Hot spots — which area is regressing fastest? Often correlates with a refactor in that part of the code.
  • Reviewing your suite — if an area has been 100% passing for six months, that’s either great or the tests aren’t actually exercising it.

​
Connecting to your tracker

If you’ve connected Linear, Jira, or Notion, areas can be linked to requirements or epics. That lets you flip the question around:
  • “Does this epic have tests?” — see every test case that traces to the epic’s tickets.
  • “Are we shipping un-tested work?” — every closed ticket without a test case linked surfaces as a gap.

​
The point

Coverage maps aren’t about a percentage on a dashboard. They’re a feedback loop: every shipped feature gets a test, every gap is visible to the team that closed it, and you can show stakeholders coverage in their own language — features, not files.