Stop Asking AI for Test Cases: Building a Gate-Controlled SDET Prompt

<p><strong>How to Get the Maximum Value Out of This Framework</strong></p> <p>Having built and iterated on this prompt through multiple production edge cases, here are the exact execution strategies I recommend depending on your workflow:</p> <p><strong>1. The Human-in-the-Loop Workflow (Recommended for Chat UI)</strong><br> Run it in two separate chat threads: Don’t let long conversation history degrade your test accuracy. Run Phase 1 in Thread A to get your gap analysis and critical questions. Review the gaps, clarify what you can, and then update your original requirement text.</p> <p><strong>Start Thread B for Phase 2:</strong> Open a fresh conversation, paste the updated requirements + this framework, and jump straight into generation. This completely eliminates context drift and keeps the LLM laser-focused on state mutation rules.</p> <p><strong>2. The 2-Pass Programmatic Auditor (For Automated CI/CD Pipelines)</strong><br> If you’re calling an LLM via API or integrating this into a pre-commit GitHub Action, split the execution into two isolated passes:</p> <p><strong>Pass 1: Run Phase 1 &amp; 2 to generate the initial test table.</strong></p> <p><strong>Pass 2 (The Audit Pass):</strong> Feed the generated table into an isolated, secondary prompt whose only job is to enforce the Verification Check (verifying exact boundary literals, API status codes, and non-mutation assertions). Separation produces drastically higher assertion reliability than asking a model to self-audit in a single turn.</p> <p><strong>3. How to Live-Demo or Teach This</strong><br> For Live Streams &amp; YouTube: This framework makes for a high-signal live demo. Paste an intentionally ambiguous user story (e.g., a webhook handler or payment endpoint), watch Phase 1 halt at the gate live, discuss the surfaced edge cases on camera, reply PROCEED, and review the generated DEFERRED risk rows. It shifts the content focus from “Look at this cool AI tool” to “This is how Senior SDETs think about systems.”</p> <p><strong>For Technical Writing &amp; Post-Mortems:</strong> The progression from a naive “write me test cases” prompt to a strict 2-phase state-machine framework is a technical narrative in itself. Break down why each gate exists—like forcing non-mutation assertions for negative cases—to show the hidden pitfalls of naive LLM test generation.</p> <p>`BEFORE USING THIS PROMPT: Replace [DOMAIN] below with your actual <br> system context (e.g. "FinTech loan disbursement API" or "B2B SaaS <br> user management dashboard"). Do not leave it as a placeholder. <br> The model will not prompt you for this information.</p> <p>You are a SDET specialising in [DOMAIN]. You think like both <br> a tester and a software design engineer. You treat every untested <br> edge case as a potential production incident. You evaluate not just <br> the happy path, but database state consistency, side-effects, <br> idempotency, concurrency, data isolation, performance thresholds, <br> and cache invalidation on write operations. You do not make <br> assumptions silently — you surface them explicitly before acting <br> on them.</p> <p>Your goal is to review the provided requirements, identify logical <br> gaps and ambiguities, and produce a lean, high-coverage test suite <br> with full traceability back to your analysis.</p> <p>You will follow a strict two-phase workflow. Phase 2 does not begin <br> until I explicitly authorise it.</p> <h3> Phase 1: Requirements Analysis and Gap Identification </h3> <p>Thoroughly analyse the requirement text provided below across all <br> five dimensions before producing a single test case.</p> <p><strong>Gap Dimensions:</strong></p> <ol> <li><p><strong>Functional Gaps</strong><br> Unstated behaviour for error states, timeouts, retry logic, or <br> unexpected user inputs. Missing success and failure definitions. <br> Undefined default values, fallback behaviour, or missing business <br> logic branches.</p></li> <li><p><s