API test plan prompt

When to use it

Use this when you need a risk-based API test plan and want a concrete starting point rather than generic advice. Replace the fictional details with your own confirmed facts before using the result in a real setting.

The prompt

## Role
Act as a backend quality engineer. Apply professional judgment while keeping your reasoning understandable to someone who is not a specialist.

## Context
A fictional appointment API exposes POST /appointments, GET /appointments/{id}, and DELETE /appointments/{id}. Appointment creation accepts a provider ID, start timestamp, and duration in minutes. Users must authenticate and may only read or cancel their own appointments. A provider cannot have overlapping active appointments. Persistence is PostgreSQL; the application framework is unspecified.

## Objective
Create an executable-quality test design before choosing a framework or writing implementation-specific test code.

## Audience
The primary users are backend teams. Make the deliverable usable in their day-to-day work, with enough explanation to support decisions but no unnecessary background lecture.

## Requirements
Cover happy paths, malformed input, boundary times, timezone offsets, ownership, cancellation behavior, concurrent booking, and database isolation. State assumptions about interval boundaries and cancellation idempotency as unresolved contract decisions. Specify setup, action, observable result, and cleanup for high-risk cases. Separate unit, integration, and end-to-end coverage; propose deterministic fixtures and a small CI smoke suite with rationale for what remains in the fuller suite.

## Constraints
Do not invent status codes as established requirements, assume UTC input is mandatory, or rely on test order or production data. Work only with the scenario and any material explicitly supplied. Label assumptions and distinguish proposed actions from confirmed facts.

## Tone & style
Be direct, thoughtful, and specific. Prefer plain English, concrete examples, and short paragraphs. Match the language to the intended reader rather than relying on jargon or generic motivational phrasing.

## Output format
Present the requested deliverable first, using descriptive headings and tables only where they improve usability. Keep supporting notes separate from copy intended for publication or direct use. Finish with a short checklist of outstanding decisions or verification steps.

## What to avoid
Avoid filler, unsupported certainty, and details invented to make the result seem more complete. Do not let a polished presentation conceal missing information or conflicting requirements.

## Success criteria
The plan exposes contract ambiguities and would catch both unauthorized access and double booking under concurrent load. Check the result against the stated constraints before presenting it and correct any inconsistencies you find.

## Clarifying questions
Ask up to three focused questions only if missing information would materially change the result. Otherwise proceed with the fictional scenario, state any necessary assumptions briefly, and identify what a real user should confirm before relying on the output.

Why it works

• The scenario gives the model concrete facts and boundaries instead of asking it to invent a brief.
• The requirements specify the actual deliverables and the important edge cases for this task.
• The constraints make unsupported claims and unapproved commitments harder to slip into the result.
• The success criteria turn review into a practical check: the plan exposes contract ambiguities and would catch both unauthorized access and double booking under concurrent load.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own context, audience, and constraints. Keep the verification steps so the final result reflects what you actually know.