Generación de Casos de Prueba (QA) con Claude

[C — Contexto] Somos [NOMBRE_EMPRESA] (empresa de software, [NÚMERO_DESARROLLADORES] desarrolladores). Lanzamos la nueva funcionalidad de [NOMBRE_FUNCIONALIDAD] en [FECHA_LANZAMIENTO]. El equipo de QA tiene [DÍAS_DISPONIBLES] días para escribir los casos de prueba. Adjunto el PRD (Product Requirements Document) de la funcionalidad. [R — Rol] Actúa como nuestro QA Lead con experiencia en testing de aplicaciones web y móviles. Tu objetivo es diseñar un plan de pruebas que detecte los bugs críticos antes del lanzamiento, no simplemente cubrir los happy paths. Los bugs más costosos son los que se detectan en producción. [E — Ejemplo] Para la funcionalidad de Login con Google del sprint anterior, diseñaste 23 casos de prueba que incluían: (1) Happy path: login exitoso con cuenta Google válida. (2) Edge case: cuenta Google con 2FA activado. (3) Escenario de fallo: timeout de red durante la autenticación OAuth. (4) Escenario de seguridad: intento de CSRF en el callback OAuth. Esos 4 tipos de casos son los que necesito para cada funcionalidad. [A — Acción] Analiza el PRD adjunto y diseña un plan de pruebas exhaustivo con al menos [NÚMERO_CASOS_PRUEBA] casos de prueba, incluyendo: (1) Happy Paths (flujos normales). (2) Edge Cases (casos límite). (3) Escenarios de fallo de red. (4) Escenarios de seguridad relevantes. Formatea la salida en una tabla con: ID, Descripción, Precondiciones, Pasos y Resultado Esperado. [T — Tono] Técnico y sistemático. Usa la terminología estándar de QA. La tabla debe poder importarse directamente a [HERRAMIENTA_GESTIÓN_TESTS] sin edición adicional. [E — Extra información] No uses los casos de prueba de la IA como única cobertura de testing: el QA lead debe revisar los casos generados antes de incluirlos en la suite. No incluyas datos de producción en los casos de prueba. Los casos de prueba de seguridad deben ser revisados por el responsable de seguridad. Copiar prompt