Gap Analyser: Better Test Coverage, Fewer Production Bugs (coming soon...)

Gaps in test coverage are how defects reach production, and they are hard to spot by eye once a test suite grows. The Gap Analyser is a Testmo MCP capability that helps you identify gaps in your test coverage, strengthen quality assurance, and reduce the risk of defects reaching production.

Give the Gap Analyser a user story, pull request or requirements, and let AI uncover hidden coverage gaps, prioritise them by severity, and highlight existing tests you can reuse. Save time, strengthen test coverage, and release with greater confidence in your software quality.

It is delivered through two tools: analyze_coverage_gaps, which submits the analysis, and get_coverage_gap_analysis, which retrieves the result. Your assistant handles both for you.

How the Gap Analyser helps

The Gap Analyser compares what should be covered with what you already test. For each scenario that no case covers, or only partly covers, it returns a gap with a severity, the impacted area and a description of the untested condition and its expected behaviour.

It also checks whether someone else has already covered the gap. Each gap can reference existing cases, including cases in other projects, that already cover part of it. Reuse those cases by copying or moving them into your project, rather than drafting new cases for the same behaviour.

You can use it in two ways:

• Against requirements. Provide a user story, specification, pull request, design or any other description of expected behaviour, and the Gap Analyser reports the scenarios your tests do not cover.
• As a brainstorming session. Provide only your existing test cases, with no requirements. The Gap Analyser infers the expected coverage from what you have already written and suggests scenarios you may be missing, such as negative flows and edge cases. Because the expected coverage is inferred, treat these results as ideas to review, not as proof that a requirement is untested.

When to use it

The Gap Analyser is most useful when it sits inside your delivery workflow, with your assistant connecting it to the tools where your requirements already live.

• Refinement and planning – Run a story, epic or specification through the Gap Analyser before development starts, so missing scenarios surface while they are cheap to fix. With the Atlassian MCP connected, your assistant can read the Jira issue or Confluence page itself and analyse it.
• Pull request review – Check a pull request or diff against your existing cases before it merges, so untested behaviour is found before it ships.
• Design and UI changes – Provide a Figma design or UI change, and see which flows your tests do not exercise.
• Release readiness – Analyse a whole project against a body of requirements, and ask for the critical and high gaps before sign-off.
• Test suite health checks and brainstorming – Analyse your existing cases on their own to find scenarios worth adding, with no requirements needed.
• Before writing new cases – Find what is missing, and what can be reused, first, so new cases are drafted only where nothing exists.

Writing a good prompt

The more clearly your prompt states what should be covered and where, the more useful the gaps. The inputs your assistant can send are:

• requirements – One or more blocks of plain text describing the expected behaviour. This can be a user story, a ticket, a specification, a pull request description or a diff. Because your own AI assistant can interpret almost any input, you can also provide a Figma design or similar material: your assistant describes it in text, and the Gap Analyser analyses that description. The Gap Analyser does not fetch links, so the content itself must be sent as text. The total input is limited by size (tokens), not by the number of projects or cases.
• project_ids – The projects whose repository cases are analysed together. Requirements are required whenever project IDs are given.
• cases_id – The IDs of specific repository cases to analyse, when you want to analyse selected cases and not whole projects. [NEEDS REVIEW – confirm exact behaviour and name against the PRD]
• test_cases – Inline cases you have drafted but not yet added to Testmo. Each needs a title, a description, and exactly one of bdd or steps. Existing repository cases belong in project_ids or cases_id, not here.
• max_gaps – The number of gaps to return, from 1 to 50. The default is 30.
• language – The language for the gap descriptions. By default, the Gap Analyser detects the language from all of the input, including the requirements and the test cases.

These combinations are accepted:

• Test cases only
• Test cases and requirements
• Requirements and projects
• All three

For example:

• “Analyse this user story against project 3 and list the gaps by severity.”
• “Check whether this pull request is covered by the test cases in project 5, and show me only the critical and high gaps.”
• “Analyse the test cases in project 3 and suggest scenarios I might be missing.” (brainstorming, no requirements)
• “Analyse these three drafted test cases against these requirements.” (for drafted cases not yet in Testmo)
• “Analyse cases 120, 121 and 134 against this specification.” (for selected cases)

Powerful combinations with the Atlassian MCP

If your assistant is also connected to the Atlassian MCP, it can fetch the requirements itself and send them to the Gap Analyser, so you do not need to copy and paste anything. Examples:

• “Read Jira issue PROJ-123, including its acceptance criteria, and analyse it against project 3. List the gaps by severity.”
• “Read the Confluence page ‘Checkout redesign spec’ and check which parts of it are not covered by project 5. Then show me the existing cases I can reuse.”
• “Take every story in the current sprint of PROJ, analyse each against project 3, and give me one summary of the critical gaps.”
• “Read the linked pull request for PROJ-456, analyse the change against project 3, and add the critical gaps as a comment on the Jira issue.”

What you get back

The Gap Analyser typically takes around a minute. When it finishes, your assistant presents a ranked list of gaps, most severe first. A completed result looks like this:

Gap Breakdown

🔴 HIGH SEVERITY GAPS

1. Artificial System Error Status Indicators (GAP-001)
  - Missing: Verification that status indicators correctly update when simulated system errors are initiated and resolved
  - Partial matches: 5 test cases cover aspects (test IDs: 100, 109, 11, 114, 123)
2. Offline Mode Caching (GAP-002)
  - Missing: Complete validation of 5-minute cache duration for last-known state
  - Partial match: Test ID 189 exists ("Verify offline caching functionality under network loss")
3. Configurable Alert Thresholds (GAP-003)
  - Missing: Tests that verify alerts actually trigger based on customizable thresholds
  - No existing test cases cover this

🟡 MEDIUM SEVERITY GAPS

4. Real-time Power System Updates (GAP-004)
  - Missing: Dedicated tests for immediate visibility of power system adjustments
  - Partial matches: 5 test cases partially cover this (IDs: 103, 112, 309, 117, 126)
5. Display Customization & Preferences (GAP-005)
  - Missing: Zoom, pan, layout customization with persistent user preferences
  - No existing test cases
6. Anomaly Recording & Reports (GAP-006)
  - Missing: Automatic anomaly detection and incident report generation
  - No existing test cases
7. Internationalization & RTL Support (GAP-007)
  - Missing: Text translatability and right-to-left language rendering
  - No existing test cases

🟢 LOW SEVERITY GAPS

8. Minimum Resolution Responsiveness (GAP-008)
  - Missing: Verification at 1024x768 resolution
  - No existing test cases

---

Recommendations

- Immediate: Add test cases for configurable alert thresholds (GAP-003) and refine existing power system response tests
- High Priority: Create tests for display customization, anomaly recording, and i18n support
- Consider: Whether 1024x768 minimum resolution is still relevant for modern mission control systems

Each gap has a gap_id, a title, a severity (critical, high, medium or low), the impacted area, a description, and a list of matching existing test cases. Each matching case shows its ID, name, project, relevance score and the aspects it already covers. The metadata gives the total number of gaps and a breakdown by severity.

If an analysis does not complete, the result tells you why:

• failed – The result includes a retryable flag. If it is true, resubmitting the same input may succeed. If it is false, change the input before resubmitting.
• cancelled – The analysis was cancelled.
• expired – The analysis expired before it completed. Submit a new one.

If an analysis takes unusually long, your assistant stops and asks whether you want to keep waiting.

Good to know and troubleshooting

• Input is too large. The message states the limit and how large the request is. It asks you to “Select fewer projects or submit fewer inline test cases.” The limit is based on input size, not on the number of projects.
• Job not found or expired. The response reads: “The coverage gap analysis job could not be found. It may have expired.” Submit a new analysis.
• Requirements are missing. Requirements must be provided whenever project IDs are given. Test cases can be analysed without requirements only when they are the whole scope.

The Gap Analyser finds gaps; it does not write test cases. Review the gaps and reuse the matching cases first. For the scenarios that remain, you can ask your assistant to propose draft test cases. These drafts stay in your conversation; nothing is saved to Testmo unless you ask your assistant to add them, which needs read-write mode.