Business Logic Abuse Test Case Generation Prompt

This prompt is built for QA engineers and security testers who need to move beyond input validation checks and directly attack the business rules of an application. The job-to-be-done is generating reproducible, step-sequencing abuse scenarios that automated scanners and standard fuzzing tools consistently miss—scenarios like skipping a payment step, applying a coupon multiple times, or approving your own purchase order. The ideal user has access to a documented multi-step business process, such as a workflow-state diagram, an API sequence specification, or a set of user-story acceptance criteria that define valid transitions and constraints. You provide the structured workflow context, and the prompt produces a set of test cases, each with a specific sequence of actions designed to violate a business rule and an expected observation that confirms the violation.

Do not use this prompt when you lack a clear definition of the intended workflow. If you cannot describe the valid states, transitions, and business rules—such as 'a cart must have a positive total before checkout' or 'an order requires manager approval above $5,000'—the model will invent plausible but irrelevant scenarios that waste testing time. This prompt is also not a replacement for a full threat model or a formal risk assessment; it is a focused generator for abuse cases that exploit logic flaws, not infrastructure vulnerabilities. For high-risk financial, healthcare, or compliance workflows, always pair the generated test cases with a human review step to confirm that the proposed abuse scenario is both legally permissible to test and correctly targets the intended business rule. The output is a starting point for test script development, not a final, executable test suite.

Before using this prompt, gather your workflow definition in a structured format. A state-transition table, a sequence diagram, or a bulleted list of steps with guard conditions all work well. The more precisely you describe the valid path, the better the model can invert it. After generating test cases, validate each one against your actual system documentation to catch any hallucinated steps or endpoints. Then prioritize the scenarios by business impact—an abuse case that allows free orders is more urgent than one that causes a minor UI glitch. Wire the highest-priority cases into your manual exploratory testing sessions or your automated regression suite, and treat the full set as a living document that evolves as your business rules change.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a malicious-but-knowledgeable QA tester, systematically probing a defined business workflow for logic flaws. The prompt requires a workflow-state diagram and a set of business rules as its primary inputs, forcing the model to reason about state transitions, preconditions, and invariant violations rather than generating generic security tests. Replace every square-bracket placeholder with your specific application context before use.

markdownCopy
You are a senior QA security tester specializing in business logic abuse. Your task is to generate a detailed test case suite that attempts to exploit workflow flaws in the application described below.

## WORKFLOW STATE DIAGRAM
[WORKFLOW_STATE_DIAGRAM_DESCRIPTION]

## BUSINESS RULES AND INVARIANTS
[BUSINESS_RULES]

## CONSTRAINTS
- Focus exclusively on logic flaws: step skipping, sequence manipulation, negative values, limit overruns, coupon/promotion stacking, and approval bypass.
- Do not generate standard injection (SQLi, XSS) or authentication brute-force tests.
- For each test case, you must identify the specific state transition or business rule being violated.
- Assume the application has standard authentication and session management; your tests should focus on what an authenticated user with a specific role can do out of order.

## OUTPUT_SCHEMA
Generate a JSON array of test case objects. Each object must conform to this exact schema:
{
  "test_cases": [
    {
      "id": "BL-XXX",
      "title": "string",
      "severity": "critical|high|medium|low",
      "abuse_scenario": "string describing the attacker's goal",
      "precondition_state": "string describing the required starting state from the diagram",
      "attack_steps": ["step 1", "step 2"],
      "violated_rule": "string referencing the specific business rule or invariant broken",
      "expected_failure_behavior": "string describing what the system should do to prevent this (e.g., show error, invalidate session, require re-authentication)",
      "remediation_guidance": "string with a brief fix suggestion"
    }
  ]
}

## RISK_LEVEL
[RISK_LEVEL]

To adapt this prompt, start by replacing [WORKFLOW_STATE_DIAGRAM_DESCRIPTION] with a textual or structured description of your application's workflow states and valid transitions. A mermaid.js diagram or a simple list of states and allowed transitions works well. Next, replace [BUSINESS_RULES] with a clear, numbered list of the application's core logic invariants, such as 'A user cannot apply more than one discount code per order' or 'An order total cannot be less than zero.' The [RISK_LEVEL] placeholder should be set to 'high', 'medium', or 'low' to guide the model on the depth and creativity of attack scenarios. For high-risk financial or compliance workflows, always pair this prompt's output with a mandatory human review step before any generated test is executed against a live-like environment.

This prompt is designed to be integrated into a security testing pipeline, not used as a one-off chat. The core input is a workflow-state diagram (or structured JSON representation of states, transitions, and guards), which the prompt uses to generate step-sequencing attacks. The harness must supply this diagram, manage the model call, validate the output against a strict schema, and log results for auditability. Because generated test cases may describe attacks that could disrupt a live system, the harness must enforce a target-environment safety check before any test execution.

The implementation should follow a validate-then-store pattern. First, call the model with the prompt template, injecting the [WORKFLOW_DIAGRAM] and [BUSINESS_RULES] as structured inputs. The model should be instructed to output a JSON array of test case objects, each with fields like test_id, attack_sequence (an ordered list of steps), abused_transition, expected_violation, and preconditions. The harness must then validate this JSON against a predefined schema, checking that all referenced states and transitions actually exist in the input diagram. Any test case referencing a non-existent state should be flagged for review or automatically discarded. For high-risk workflows (e.g., payments, approvals), route all generated test cases to a human-in-the-loop review queue before they are ever executed or stored in a shared test repository.

For model selection, a model with strong reasoning capabilities is required to trace multi-step abuse paths. Use a low temperature (0.1–0.2) for deterministic, reproducible outputs. Implement a retry loop with a repair prompt if the initial JSON output fails schema validation; the repair prompt should provide the specific validation errors and ask the model to fix only the malformed records. Log the raw prompt, the full model response, the validation result, and the reviewer's decision for each generation run. This creates an audit trail that proves test cases were machine-generated and reviewed, which is critical for compliance-focused teams. Avoid wiring this directly to a test execution engine without a human approval gate and a strict environment check to prevent accidental disruption of production systems.