Prompt para plan de pruebas de API

Cuándo usarlo

Utiliza esto cuando necesites un plan de pruebas de API basado en riesgos y busques un punto de partida concreto en lugar de consejos genéricos. Sustituye los detalles ficticios por tus propios datos confirmados antes de utilizar el resultado en un entorno real.

El prompt

## Rol
Actúa como un ingeniero de calidad de backend (QA backend). Aplica tu criterio profesional manteniendo un razonamiento comprensible para alguien que no sea especialista.

## Contexto
Una API ficticia de citas expone POST /appointments, GET /appointments/{id} y DELETE /appointments/{id}. La creación de citas acepta el ID del proveedor, la marca de tiempo de inicio (timestamp) y la duración en minutos. Los usuarios deben autenticarse y solo pueden consultar o cancelar sus propias citas. Un proveedor no puede tener citas activas superpuestas. La persistencia es PostgreSQL; el framework de la aplicación no está especificado.

## Objetivo
Crear un diseño de pruebas con calidad ejecutable antes de elegir un framework o escribir código de prueba específico de la implementación.

## Audiencia
Los usuarios principales son equipos de backend. Haz que el entregable sea utilizable en su trabajo diario, con explicaciones suficientes para respaldar las decisiones pero sin teoría innecesaria.

## Requisitos
Cubre caminos felices (happy paths), entradas malformadas, límites temporales, desfases de zona horaria (offsets), propiedad de los datos, comportamiento de cancelación, reservas concurrentes y aislamiento de la base de datos. Declara las suposiciones sobre los límites de los intervalos y la idempotencia de la cancelación como decisiones de contrato aún no resueltas. Especifica la preparación (setup), la acción, el resultado observable y la limpieza (cleanup) para los casos de alto riesgo. Separa la cobertura unitaria, de integración y de extremo a extremo (E2E); propone fixtures deterministas y una pequeña suite de smoke tests para CI con la justificación de qué se delega a la suite completa.

## Restricciones
No inventes códigos de estado como si fueran requisitos establecidos, no asumas que la entrada en UTC es obligatoria ni dependas del orden de las pruebas o de datos de producción. Trabaja únicamente con el escenario y con el material explícitamente suministrado. Etiqueta las suposiciones y distingue las acciones propuestas de los hechos confirmados.

## Tono y estilo
Sé directo, reflexivo y específico. Prefiere un lenguaje claro, ejemplos concretos y párrafos cortos. Adapta el lenguaje al lector previsto en lugar de recurrir a tecnicismos excesivos o frases motivacionales genéricas.

## Formato de salida
Presenta primero el entregable solicitado, utilizando encabezados descriptivos y tablas solo donde mejoren la usabilidad. Mantén las notas complementarias separadas del texto destinado a publicación o uso directo. Finaliza con una breve lista de verificación de decisiones pendientes o pasos de verificación.

## Qué evitar
Evita el texto de relleno, la certeza sin fundamento y los detalles inventados para que el resultado parezca más completo. No permitas que una presentación impecable oculte información faltante o requisitos contradictorios.

## Criterios de éxito
El plan expone las ambigüedades del contrato y detectaría tanto accesos no autorizados como reservas duplicadas bajo carga concurrente. Revisa el resultado frente a las restricciones establecidas antes de presentarlo y corrige cualquier inconsistencia que encuentres.

## Preguntas de aclaración
Haz un máximo de tres preguntas específicas solo si la falta de información alterara sustancialmente el resultado. De lo contrario, continúa con el escenario ficticio, declara brevemente las suposiciones necesarias e identifica qué debería confirmar un usuario real antes de confiar en el resultado.

Por qué funciona

• El escenario proporciona al modelo hechos y límites concretos en lugar de pedirle que invente un brief.
• Los requisitos especifican los entregables reales y los casos extremos importantes para esta tarea.
• Las restricciones dificultan que se cuelen en el resultado afirmaciones sin respaldo o compromisos no aprobados.
• Los criterios de éxito convierten la revisión en una comprobación práctica: el plan expone ambigüedades del contrato y detectaría tanto el acceso no autorizado como la doble reserva bajo carga concurrente.

Adáptalo a tu caso

Crea una versión personalizada con PromptDeck sustituyendo el escenario ficticio por tu propio contexto, audiencia y restricciones. Mantén los pasos de verificación para que el resultado final refleje lo que realmente sabes.