Defect Reproduction Automation Feasibility Assessment Prompt

This prompt is for SDETs and automation engineers who need to decide whether a manual defect reproduction procedure is worth automating. The job-to-be-done is a structured feasibility assessment that produces a clear recommendation, not just a yes/no answer. The ideal user has access to the manual reproduction steps, knowledge of the target automation framework (Playwright, Selenium, Cypress), and understanding of the application's UI architecture. The prompt expects you to provide the manual reproduction steps, known environment details, and any prior automation context for the affected feature area.

Use this prompt when the cost of repeated manual reproduction justifies an automation investment decision. It works best for UI-driven defects where selectors, wait conditions, and state transitions are the primary automation concerns. The prompt is also appropriate when you need to justify automation ROI to stakeholders or when you're prioritizing a backlog of manual test cases for automation. It produces a feasibility score, selector stability assessment, automation approach recommendation, estimated effort in hours, and maintenance risk flags—all of which feed directly into sprint planning and automation roadmap decisions.

Do not use this prompt for defects that are purely backend, API-level, or data-state issues where UI automation adds no value. It is not designed for performance or load-related defects, security vulnerabilities requiring specialized tooling, or defects where the reproduction steps are still ambiguous. If the manual reproduction steps are incomplete or the defect is not reliably reproducible, resolve those gaps first using a defect structuring prompt before assessing automation feasibility. The prompt assumes you have a stable manual reproduction procedure as input; garbage in will produce an unreliable feasibility score out.

This prompt template is the core of the feasibility assessment workflow. It is designed to receive a structured defect record and return a detailed automation feasibility analysis. The template uses square-bracket placeholders to enforce a strict contract between the application layer and the model. You must populate these placeholders with real data before sending the prompt to the model. The most critical inputs are the reproduction steps, the target application's technology stack, and the automation framework you intend to use.

textCopy
You are an SDET Architect evaluating the feasibility of automating a manual defect reproduction. Your analysis must be data-driven, focusing on selector stability, step complexity, and maintenance risk. Do not recommend automation if the cost of maintenance outweighs the value of automated regression coverage.

## DEFECT RECORD
[STRUCTURED_DEFECT_RECORD]

## TARGET CONTEXT
- Application URL: [APPLICATION_URL]
- Technology Stack: [TECH_STACK]
- Target Automation Framework: [AUTOMATION_FRAMEWORK]
- Existing Test Infrastructure Notes: [EXISTING_INFRA_NOTES]

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this exact structure. Do not include any text outside the JSON object.
{
  "feasibility_score": <number 0-100, where 100 is trivially automatable>,
  "recommendation": "<Automate | Conditionally Automate | Do Not Automate>",
  "selector_stability_assessment": {
    "score": <number 0-100>,
    "fragile_selectors": ["<list of unstable selectors>"],
    "recommended_selectors": ["<list of robust alternative selectors>"]
  },
  "step_automation_complexity": [
    {
      "step_number": <integer>,
      "original_step": "<text>",
      "automation_approach": "<description of how to automate>",
      "risk": "<Low | Medium | High>",
      "risk_rationale": "<explanation>"
    }
  ],
  "estimated_effort_hours": <number>,
  "maintenance_risk_flags": ["<list of factors that will cause this test to break often>"],
  "roi_justification": "<concise justification for the recommendation>"
}

## CONSTRAINTS
- Base your assessment strictly on the provided defect record and target context.
- If the defect record lacks clear reproduction steps, the feasibility_score must be 0 and the recommendation must be "Do Not Automate".
- Flag any step that requires a human visual check (e.g., "check if the color is slightly off") as High risk.
- If the target application uses a dynamic UI framework (e.g., React, Angular), assume selectors are fragile unless data-testid attributes are confirmed to be present.
- The estimated_effort_hours must account for script development, debugging, and integration into the existing test suite.

To adapt this template, start by replacing the placeholders in the TARGET CONTEXT section. The [TECH_STACK] placeholder should be a concise string like "React 18, Next.js, Tailwind CSS" to guide selector strategy. The [AUTOMATION_FRAMEWORK] placeholder should specify the exact tool, such as "Playwright (TypeScript)" or "Selenium 4 (Java)", as this dictates the syntax of the automation_approach in the output. The most critical adaptation is populating [STRUCTURED_DEFECT_RECORD] with a complete, machine-readable defect object, not just a block of text. A well-structured input might look like: {"id": "BUG-101", "title": "...", "steps": [{"action": "...", "expected": "...", "actual": "..."}], "environment": "..."}. This structured input is essential for the model to accurately parse steps and assess complexity.

This prompt is designed to be called programmatically as part of a defect triage or automation planning workflow. The primary integration point is after a manual reproduction procedure has been documented and before an automation engineer commits to scripting it. The prompt expects a structured defect record with reproduction steps, environment details, and selector information as input. In a typical pipeline, a ticketing system webhook or a test management tool trigger fires when a defect is marked 'Candidate for Automation,' sending the defect payload to an orchestration layer that calls the LLM with this prompt template.

The implementation should include a pre-validation step that checks the input defect record for required fields before calling the model. Missing reproduction steps, absent environment details, or empty selector fields should cause the request to be rejected early with a clear error message rather than producing a low-confidence feasibility assessment. After the model responds, a post-validation layer must parse the JSON output and verify that the feasibility_score is a number between 0 and 1, that automation_approach is one of the expected enum values, and that estimated_effort_hours is a positive number. If the output fails schema validation, retry once with a repair prompt that includes the validation error. If the retry also fails, route the defect to a human reviewer queue with the raw model output attached. For model choice, a capable mid-tier model like claude-3-5-sonnet or gpt-4o is appropriate; this task requires structured reasoning about testability but not the largest available context window.

Logging and observability are critical because this prompt influences resource allocation decisions. Log the input defect ID, the model's feasibility score, the automation approach recommendation, and the selector stability assessment to your observability platform. Track the maintenance_risk_flags array over time to identify patterns—if the model consistently flags CSS class-based selectors as high-risk, that signal should feed back into your selector strategy. For human review gates, route any assessment with a feasibility score between 0.4 and 0.6 to an SDET for manual judgment. Assessments with maintenance_risk_flags containing 'high' severity items should also trigger review, even if the feasibility score is above 0.7. The ROI justification field should be surfaced in your automation planning dashboard alongside the estimated effort so that prioritization decisions are evidence-backed. Do not use this prompt for security-sensitive defects where reproduction details should not leave your environment; those require an air-gapped or local model deployment.