Auth Integration Test Case Generation Prompt

This prompt is designed for QA engineers and security testers who need to generate structured, traceable test cases from authentication API documentation. It takes an OpenAPI spec, auth flow description, or endpoint reference as input and produces a categorized test suite covering happy path, negative scenarios, edge cases, and race conditions. Use this prompt when you have stable API documentation and need to accelerate test planning, catch missing negative test scenarios, or standardize test case formatting across an auth testing team.

Do not use this prompt when the API documentation is incomplete, when you need executable test code rather than test case descriptions, or when the auth scheme is custom and undocumented. The prompt assumes the input documentation includes grant types, token formats, error responses, scope definitions, and endpoint-level auth requirements. If your documentation is missing these elements, the generated test cases will contain gaps that require manual backfill before they can be trusted for coverage planning.

The ideal input is a complete OpenAPI specification or a well-structured auth reference page that explicitly defines token lifetimes, refresh semantics, error codes, and scope-to-endpoint mappings. Before running this prompt, verify that your source documentation includes the required sections. If it does not, use a documentation completeness audit prompt first to identify gaps, then return to this prompt once the source material is stable. The output is a test case catalog, not a test script—pair it with a test automation framework to convert descriptions into executable checks.

This prompt template generates structured test cases for authentication and authorization flows directly from your API documentation. It covers happy-path scenarios, token expiry, invalid credentials, scope escalation attempts, and race conditions. Replace the square-bracket placeholders with your actual API documentation, test environment details, and output format requirements before sending to the model. The template is designed to produce test cases that QA engineers can immediately execute or adapt into automated test suites.

textCopy
You are a senior QA engineer specializing in authentication and authorization testing. Your task is to generate a comprehensive test case suite from the provided API documentation.

## INPUT
API Documentation:
[DOCUMENTATION]

Auth Flow Type: [FLOW_TYPE]
Example: OAuth 2.0 Authorization Code with PKCE, API Key header auth, JWT bearer token, Session cookie auth

Test Environment:
- Base URL: [BASE_URL]
- Test Credentials Available: [CREDENTIALS_AVAILABLE]
- Rate Limit Constraints: [RATE_LIMITS]

## OUTPUT_SCHEMA
Return a JSON array of test case objects with this exact structure:
{
  "test_cases": [
    {
      "id": "AUTH-[CATEGORY]-[NUMBER]",
      "title": "Descriptive test case name",
      "category": "happy_path | token_lifecycle | invalid_credentials | scope_escalation | race_condition | error_handling | security_boundary",
      "priority": "P0 | P1 | P2",
      "preconditions": ["Required state before test execution"],
      "steps": ["Step-by-step actions to perform"],
      "expected_result": {
        "status_code": 200,
        "response_body_assertions": ["Specific field checks"],
        "token_assertions": ["Token format, expiry, scope checks if applicable"]
      },
      "cleanup": ["Steps to restore state after test"],
      "automation_notes": "Framework-specific hints for automation",
      "risk_notes": "Security or reliability implications if this test fails"
    }
  ]
}

## CONSTRAINTS
1. Generate at least [MIN_TEST_COUNT] test cases covering all specified categories.
2. For every endpoint in the documentation that requires authentication, generate at least one happy-path and one invalid-credential test case.
3. For every scope or permission defined, generate at least one scope escalation test case.
4. Include token expiry test cases for every token type mentioned (access, refresh, ID tokens).
5. Flag any missing negative test scenarios you identify but cannot fully specify due to documentation gaps. Add them to a "coverage_gaps" array.
6. Use the exact endpoint paths, parameter names, and error codes from the documentation.
7. Do not invent endpoints, scopes, or error codes not present in the provided documentation.

## EXAMPLES
Example test case for reference:
{
  "id": "AUTH-HAPPY-001",
  "title": "Valid client credentials grant returns access token",
  "category": "happy_path",
  "priority": "P0",
  "preconditions": ["Valid client_id and client_secret registered in test environment"],
  "steps": [
    "POST to /oauth/token with grant_type=client_credentials",
    "Include client_id and client_secret in request body",
    "Verify response status code"
  ],
  "expected_result": {
    "status_code": 200,
    "response_body_assertions": [
      "access_token is present and non-empty",
      "token_type is 'Bearer'",
      "expires_in is a positive integer"
    ],
    "token_assertions": [
      "access_token is a valid JWT with correct signing algorithm",
      "exp claim is set to current time plus expires_in seconds"
    ]
  },
  "cleanup": ["No cleanup required for stateless token request"],
  "automation_notes": "Use OAuth client library for token request. Store token for subsequent authenticated requests.",
  "risk_notes": "Core authentication flow. Failure blocks all authenticated API access."
}

## TOOLS
You may reference these testing patterns:
- Token replay detection: Send the same token twice and verify second request is accepted or rejected per spec
- Race condition testing: Send simultaneous requests with expiring tokens to verify atomic refresh behavior
- Scope escalation: Use a token with scope A to access an endpoint requiring scope B

## RISK_LEVEL
[HIGH_RISK_DOMAINS]
If the documentation covers financial, healthcare, or PII-accessing endpoints, mark all related test cases as P0 and add a "compliance_note" field referencing relevant regulations.

Adaptation guidance: Replace [DOCUMENTATION] with your full API reference, including endpoint definitions, auth schemes, error codes, and scope definitions. Set [FLOW_TYPE] to match your auth implementation. Adjust [MIN_TEST_COUNT] based on your API surface area—a good starting point is 15-20 test cases for a typical REST API with 10-15 authenticated endpoints. For [HIGH_RISK_DOMAINS], specify applicable regulations such as PCI-DSS, HIPAA, or SOC 2 to trigger compliance-aware test generation. The output schema is designed to feed directly into test management tools like TestRail, Zephyr, or Xray. If your team uses a different test case format, modify the OUTPUT_SCHEMA section to match your tool's import format before running the prompt.

Validation and next steps: After generating test cases, validate that every documented endpoint appears in at least one test case. Check that all error codes from the documentation are covered by at least one negative test scenario. Run a manual review pass on scope escalation test cases to confirm they test actual permission boundaries rather than hypothetical ones. For high-risk domains, have a security engineer review the generated test cases before adding them to your regression suite. Store the generated test cases in version control alongside your API documentation so they can be regenerated when the API changes.

This prompt is designed to be called programmatically, not just used in a chat interface. The primary integration point is a QA test generation service that accepts an API specification (OpenAPI, a markdown doc, or a structured endpoint list) and returns a structured test case payload. The harness must validate the output against a strict schema before any test case is written to a test management tool or executed. Because auth test cases directly touch security boundaries, a human review step is mandatory before promotion to an automated regression suite.

Wire the prompt into an application by first constructing the input context from your source of truth. If you maintain an OpenAPI spec, extract the security and securitySchemes blocks, along with the relevant endpoint definitions, and inject them into the [API_SPECIFICATION] placeholder. For the [AUTH_SCHEME_DETAILS] placeholder, provide a structured JSON object describing grant types, token endpoints, refresh policies, and scope definitions. The model should be instructed to output a JSON array of test case objects conforming to a predefined [OUTPUT_SCHEMA]. After generation, run a validation layer that checks for required fields (test_id, description, preconditions, steps, expected_result, risk_level), ensures all specified endpoints are covered, and flags any missing negative test categories like token expiry, invalid scope escalation, or race conditions. Log every generation attempt with the prompt version, input hash, and raw output for debugging.

For production use, choose a model with strong JSON mode and instruction-following capabilities. Set temperature to 0 to maximize determinism. Implement a retry strategy: if the output fails schema validation, feed the validation errors back into the prompt as [PREVIOUS_OUTPUT] and [VALIDATION_ERRORS] and request a repair. Limit retries to 2 attempts before escalating to a human reviewer. The final step in the harness should be a review queue integration—automatically create a ticket or PR that contains the generated test cases, a diff against the existing test suite, and a checklist for the reviewer to confirm coverage of OWASP auth testing guidelines. Do not allow auto-commit to the main test branch without this approval.