Happy-Path vs Sad-Path Coverage Comparison Prompt

This prompt is for test architects and QA leads who need to quantify the balance between positive and negative test coverage across a system or feature area. The job-to-be-done is producing a structured comparison report that identifies over-tested happy paths and under-tested error, exception, and failure scenarios. Use it when you have a list of existing test cases and a set of functional paths or requirements, and you need evidence to justify rebalancing test effort toward resilience and error handling. The ideal user has access to test case titles, descriptions, or tags, and understands the system's expected behavior under both normal and failure conditions.

Do not use this prompt when you lack a defined set of functional paths to compare against. If your test cases are not categorized or you cannot distinguish happy-path from sad-path scenarios with reasonable confidence, the output will be speculative rather than actionable. This prompt is also not a substitute for a full risk-based test assessment—it focuses narrowly on the happy/sad ratio and does not evaluate security, performance, or compliance coverage. For regulated domains, always pair the output with a human review step and cross-reference against your traceability matrix before making resourcing decisions.

Before running this prompt, gather your test case inventory and a list of functional paths or user stories. The prompt expects you to provide both, along with a classification schema for what counts as a happy path versus a sad path in your context. After receiving the comparison report, validate the path classifications against your own domain knowledge—models can misclassify ambiguous scenarios. Use the coverage ratio scoring to prioritize new test creation, but do not treat the ratio alone as a quality gate. The next step is typically feeding the identified gaps into a test case generation workflow or a risk-based test planning session.

This template is designed for test architects and QA leads who need to evaluate the balance between positive and negative test coverage across a feature, module, or system. It accepts a list of existing test cases and their classifications, then produces a comparison report that identifies over-tested happy paths and under-tested error, exception, and failure scenarios. The prompt is structured to enforce path classification validation and coverage ratio scoring, making it suitable for risk-based test planning and compliance review workflows. Before using this template, ensure you have a reasonably complete inventory of test cases with their intended path types—this prompt diagnoses coverage balance, not test case completeness.

textCopy
You are a test architect evaluating the balance between happy-path and sad-path test coverage for a software system. Your task is to analyze the provided test cases, classify each as happy-path or sad-path, and produce a structured comparison report identifying coverage gaps.

## INPUT
Test cases with descriptions and any existing path classifications:
[TEST_CASES]

Feature or module context:
[FEATURE_CONTEXT]

## CLASSIFICATION RULES
- Happy-path: Tests where all inputs are valid, preconditions are met, and the system completes its primary intended behavior without errors.
- Sad-path: Tests involving invalid inputs, missing preconditions, authentication failures, authorization denials, resource unavailability, timeouts, malformed data, boundary violations, or explicit error/exception handling.
- If a test case cannot be confidently classified, flag it as [UNCERTAIN] and explain why.

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "summary": {
    "total_tests": <number>,
    "happy_path_count": <number>,
    "sad_path_count": <number>,
    "uncertain_count": <number>,
    "happy_path_percentage": <number>,
    "sad_path_percentage": <number>,
    "coverage_ratio": "<happy>:<sad>"
  },
  "classification_review": [
    {
      "test_id": "<string>",
      "description": "<string>",
      "original_classification": "<string or null>",
      "assigned_classification": "happy|sad|uncertain",
      "rationale": "<string>"
    }
  ],
  "gap_analysis": {
    "over_tested_happy_paths": ["<patterns or scenarios with excessive happy-path coverage>"],
    "under_tested_sad_paths": [
      {
        "scenario": "<description of missing error/exception scenario>",
        "risk_level": "high|medium|low",
        "suggested_test_count": <number>
      }
    ],
    "missing_error_categories": ["<error types with zero coverage>"]
  },
  "recommendations": [
    {
      "action": "<string>",
      "priority": "high|medium|low",
      "rationale": "<string>"
    }
  ]
}

## CONSTRAINTS
- Classify every test case individually; do not assume classifications from test names alone.
- If original classifications are provided, note discrepancies between original and assigned classifications in the rationale field.
- Flag any test case that appears to test both happy and sad paths as uncertain and recommend splitting it.
- A healthy coverage ratio target is between 40:60 and 60:40 (happy:sad). Ratios outside this range should trigger high-priority recommendations.
- For regulated or safety-critical systems, sad-path coverage below 40% must be flagged as a critical gap.

## EVALUATION CRITERIA
A valid output must:
1. Classify 100% of provided test cases.
2. Provide specific, actionable gap descriptions, not generic advice.
3. Include risk levels for all identified gaps.
4. Justify any recommendation to add tests with a concrete scenario description.

## RISK LEVEL
[RISK_LEVEL]  // Use "standard" for most applications; use "safety-critical" for medical, aviation, industrial control, or financial settlement systems to enforce stricter ratio requirements.

To adapt this template, replace [TEST_CASES] with your actual test inventory—ideally exported from your test management system with IDs and descriptions. The [FEATURE_CONTEXT] placeholder should contain a brief description of the feature or module under analysis to ground the classification decisions. Set [RISK_LEVEL] to "safety-critical" when analyzing systems where failures can cause harm, financial loss, or regulatory violations; this tightens the acceptable ratio range and escalates gap severity. For production use, validate the output JSON against the schema before ingestion, and consider running this analysis per-release as part of your quality gate checks. If your test cases lack descriptions detailed enough for classification, run a test documentation improvement pass first—this prompt cannot compensate for vague or missing test case metadata.

This prompt is designed to operate as a batch analysis step within a QA intelligence pipeline, not as a real-time chat interaction. The typical integration pattern involves feeding the prompt a structured payload containing a list of test cases and their associated requirements, then receiving a scored comparison report. Because the output includes coverage ratios and gap classifications that may influence release decisions, the implementation must include automated validation of the output schema, scoring consistency checks, and a human review gate before findings are committed to a test management system like TestRail, Xray, or Azure Test Plans.

To wire this into an application, construct the input payload by joining data from your test case repository and requirements store. The [TEST_CASES] placeholder expects an array of objects with id, title, steps, and linked_requirements fields. The [REQUIREMENTS] placeholder expects objects with id, description, and acceptance_criteria. Before calling the model, run a pre-validation step to ensure every test case has a non-empty steps array and every requirement has at least one acceptance criterion. After receiving the model response, validate the output against the expected schema: a JSON object containing coverage_summary, happy_path_tests, sad_path_tests, gap_analysis, and recommendations arrays. Reject any response where the coverage_ratio field is not a number between 0 and 1, or where gap_analysis entries lack a severity field. Log the raw prompt, response, and validation result for auditability.

For high-stakes releases, implement a dual-model verification pattern: send the same input to two different models (e.g., Claude and GPT-4) and compare the coverage ratios and top-5 gap findings. If the ratios diverge by more than 15% or the gap lists disagree on high-severity items, flag the analysis for mandatory human review. Store the comparison delta alongside the final report. Avoid using this prompt on test suites exceeding 200 test cases in a single call—chunk large suites by functional area and aggregate the results in a post-processing step. The next step after implementation is to build a regression test that runs this prompt against a known golden dataset with pre-labeled happy-path and sad-path classifications to measure classification accuracy before trusting it on production test suites.