End-to-End Test Gap Analysis Prompt

This prompt is designed for QA leads and engineering teams assessing integration coverage across service boundaries. Use it when a code change spans multiple services, APIs, or data stores and you need to understand which user journeys are affected and whether end-to-end tests exist for the changed behavior. The prompt maps code diffs to system flows, traces cross-service interactions through the full call chain, and produces a structured journey-to-test mapping with gaps highlighted. This is not a unit test gap tool. Use it when the risk is in the interactions between components, not within a single function or file. The output is a decision artifact for release readiness, not a replacement for human QA judgment on critical paths.

The ideal user brings three pieces of context: a concrete code diff or changeset, a description or diagram of the system's service topology and user journeys, and an inventory of existing end-to-end tests with their coverage scope. Without all three, the prompt will produce plausible-sounding but ungrounded output. The prompt works best when the system has well-defined integration points—API contracts, message queues, shared databases—and when the change touches those boundaries. For monoliths or single-service changes, use the PR Diff Test Coverage Gap Analysis Prompt instead. For unit-level gaps, use the Untested Code Path Identification Prompt. This prompt adds value when the question is 'which user flows did we forget to test end-to-end?' not 'did we cover every branch in this function?'

Do not use this prompt for real-time CI/CD gating without human review. The analysis requires reasoning about distributed system behavior, which carries inherent uncertainty. The prompt can miss indirect coupling (e.g., a shared cache invalidation that affects a seemingly unrelated journey) and cannot verify whether existing end-to-end tests actually assert the changed behavior rather than just touching the affected services. Always pair the output with a human QA lead who can validate the journey mappings and assess whether flagged gaps represent real risk. For regulated or safety-critical systems, treat the prompt's output as a starting point for a formal test coverage review, not as evidence of completeness.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a QA architect, tracing a given code change through the full system call chain and mapping it to known user journeys. The core output is a structured gap analysis: which journeys are affected, which have end-to-end tests, and which lack coverage for the new behavior. Before using this prompt, you must have a clear understanding of the code change, the system's service topology, and a catalog of existing end-to-end tests. This prompt is not a replacement for a human QA lead's judgment; it is a force-multiplier that surfaces blind spots before they reach production.

textCopy
You are a QA architect specializing in end-to-end test gap analysis for distributed systems. Your task is to analyze a code change and determine its impact on user journeys across service boundaries.

## INPUTS
[CODE_CHANGE_DIFF]
[SERVICE_TOPOLOGY]
[EXISTING_E2E_TESTS]
[JOURNEY_CATALOG]

## INSTRUCTIONS
1. Parse the [CODE_CHANGE_DIFF] to identify the specific logic, API contract, or data flow that has been modified.
2. Using the [SERVICE_TOPOLOGY], trace the change through all downstream and upstream service dependencies. Identify every service that is directly or indirectly affected.
3. Map the affected services and data flows to the [JOURNEY_CATALOG]. List every user journey that exercises any part of the modified call chain.
4. For each identified journey, check the [EXISTING_E2E_TESTS] to determine if there is a test that covers the specific behavior changed. A test only counts as coverage if it would fail when the new behavior is broken.
5. Classify each journey into one of three categories:
   - **COVERED**: An existing E2E test validates the changed behavior for this journey.
   - **PARTIALLY_COVERED**: The journey is tested, but the specific modified path, edge case, or service interaction is not exercised.
   - **GAP**: No E2E test exists for this journey, or existing tests do not touch the affected services.
6. For every PARTIALLY_COVERED or GAP journey, provide a concrete test scenario recommendation. Include the entry point, required test data, expected service interactions, and the assertion that would catch a regression.

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "change_summary": "string describing the change and its blast radius",
  "affected_services": ["service_name"],
  "journey_analysis": [
    {
      "journey_id": "string",
      "journey_name": "string",
      "coverage_status": "COVERED | PARTIALLY_COVERED | GAP",
      "existing_test_ids": ["string"],
      "gap_description": "string explaining what is not covered (null if COVERED)",
      "recommended_test": {
        "scenario_name": "string",
        "entry_point": "string (API call, UI action, event)",
        "test_data_requirements": "string",
        "expected_service_interactions": ["string"],
        "critical_assertions": ["string"]
      } // null if COVERED
    }
  ],
  "overall_risk_assessment": "LOW | MEDIUM | HIGH | CRITICAL",
  "blocking_gaps": ["journey_id"] // journeys that must have tests before merge
}

## CONSTRAINTS
- Do not invent journeys or services not present in the provided catalogs.
- If the change is purely cosmetic or has no functional impact on any journey, state that explicitly and return an empty journey_analysis array.
- A test that only checks HTTP 200 is not sufficient coverage. Require behavioral assertions.
- Flag as CRITICAL risk any change that affects authentication, authorization, payment, or data deletion flows without full E2E coverage.

To adapt this template, replace the square-bracket placeholders with structured data from your systems. [CODE_CHANGE_DIFF] should be a unified diff or a clear description of the change. [SERVICE_TOPOLOGY] can be a textual description of service dependencies, a simplified architecture diagram in text, or a structured JSON list of services and their call relationships. [EXISTING_E2E_TESTS] should include test names, IDs, and the journeys they cover. [JOURNEY_CATALOG] is your canonical list of user journeys with their steps and involved services. If your harness cannot provide all four inputs, the prompt's accuracy will degrade; in that case, consider a narrower prompt like the PR Diff Test Coverage Gap Analysis Prompt instead.

After pasting this prompt, validate the output against the schema before acting on it. A common failure mode is the model hallucinating journeys or tests that do not exist in your catalog. Always cross-reference the returned journey_ids and test_ids against your source of truth. For high-risk changes, a human QA lead must review the gap analysis before it is used as a merge gate. Do not treat this prompt's output as a substitute for a formal risk assessment in regulated environments.

This prompt is designed to run as a pre-merge analysis step in a CI/CD pipeline, triggered when a pull request modifies code that crosses service boundaries. The harness must supply the prompt with a structured diff, a service dependency map, and a list of existing end-to-end test scenarios. The model's output—a journey-to-test mapping with gaps highlighted—should be treated as an advisory signal, not a blocking gate, until the team has calibrated the prompt's accuracy against known regressions over several release cycles.

To integrate, build a pipeline stage that: (1) extracts the code diff and identifies which services and API contracts changed; (2) retrieves the current end-to-end test catalog from the test management system; (3) assembles the prompt with the diff, the service topology graph, and the test catalog; (4) sends the request to a model with strong reasoning capabilities (GPT-4o or Claude 3.5 Sonnet are appropriate starting points); and (5) parses the structured output into a gap report. Validation is critical: the harness must verify that every flagged gap references a specific code change and a specific user journey. If a gap cannot be traced to a diff hunk, discard it or flag it for human review. Log the raw prompt, model response, and validation results for auditability.

For high-risk services (payments, auth, data deletion), add a human review step before the gap report is published to the PR thread. The harness should also track whether gaps identified by the prompt later correlate with production incidents—this feedback loop is essential for tuning the prompt's risk language and for deciding when to promote the analysis from advisory to a merge-blocking check. Start with a shadow mode deployment where the prompt runs silently alongside existing review processes for at least two sprints before acting on its output.