Plan de QA
Derive el plan de pruebas base para una Historia de Usuario mediante un examen socrático: condiciones de prueba con técnicas de diseño declaradas, resultados esperados aseverados solo cuando las especificaciones los respaldan, y preguntas dirigidas a quien pueda resolver el resto. No pregunte "¿está bien escrita esta historia?", eso es /refine-story. Usted responde: ¿qué puede fallar?, ¿cómo demuestro que funciona?, y ¿qué debe existir para ejecutar esa demostración?
Un ingeniero de QA de nivel medio debería poder implementar pruebas directamente a partir de este artefacto; un ingeniero de QA senior debería estar de acuerdo con su priorización.
US: $ARGUMENTS
Límite de tres capas
Derivar condiciones no escritas es la esencia de QA, siempre que siga métodos establecidos. Por lo tanto, el límite aquí opera a través de tres capas; la base sigue siendo requirements-rigor. Cada condición en el plan pertenece exactamente a una capa:
[ESPECIFICADO: trecho]: la condición y el resultado esperado se originan directamente del texto. Cite la fuente.[DERIVADO: técnica]: la condición se deriva de una técnica de diseño de pruebas aplicada a lo especificado. Siempre nombre la técnica; una condición sin técnica declarada es una suposición y no debe ingresar. Los resultados esperados solo pueden aseverarse si se siguen lógicamente de la especificación.[INDEFINIDO → Pregunta n]: una condición legítima cuyo resultado esperado la especificación no define. La condición ingresa en la matriz; el resultado se convierte en una pregunta numerada.
Prueba rápida: "¿qué técnica generó esta condición, y de qué extracto se deriva?" Si alguna de las dos no puede responderse, exclúyala del plan.
Antes de comenzar
Lea docs/agents/refinement.md en el espacio de trabajo: define el modo de operación (con o sin código), el idioma (en-US o pt-BR, predeterminado en-US) y las rutas de publicación. El modo define quién responde preguntas arquitectónicas: con código, usted las resuelve inspeccionando la base de código; sin código, el equipo de ingeniería las resuelve mediante cuestionarios. El examen socrático y el plan de QA se redactan en el idioma configurado. Si el archivo falta, solicite /configure-refinement y deténgase.
Pasos
-
Cargar. Lea la US,
CONTEXT.md, los ADR del dominio, TEST-DESIGN.md, e invoque la herramienta Skill pararequirements-rigor. Si.scratch/<slug>/spec.mdexiste de/refine-story, comience desde allí: las decisiones de esa sesión ya responden muchas preguntas. Sin este archivo, trate la US como no refinada, incluso siStatus:dice LISTA. Completado cuando: el triaje de testabilidad se indica en una sola línea: TESTABLE (cada resultado esperado tiene un punto de observación y ninguna dependencia está pendiente de confirmación), TESTABLE CON RESERVAS (se pueden derivar condiciones, pero al menos un resultado carece de punto de observación o depende de dependencias no confirmadas), o NO TESTABLE. -
Triaje. NO TESTABLE (los criterios no describen comportamiento observable: exclusivamente tareas, o términos subjetivos sin métricas en todos los criterios): explique qué falta, enumere de 3 a 5 preguntas mínimas y recomiende
/refine-story. Deténgase aquí; analizar material no comprobable produce planes de fachada. Si la US no ha pasado por refinamiento, indíquelo y continúe, señalando que muchas preguntas serían resueltas por/refine-story. Completado cuando: se declara el triaje. -
Derivar condiciones. Para cada criterio, aplique las técnicas aplicables de TEST-DESIGN.md, evitando forzar técnicas inaplicables, y revise ángulos silentes, reportando solo los aplicables. Construya la matriz: condición, origen, resultado esperado o
[INDEFINIDO → Pregunta n], prioridad, capa. Las condiciones indefinidas permanecen en la matriz: una cobertura futura visible es mucho mejor que brechas ocultas. Numere las preguntas en una sola secuencia combinando PO y DEV, para que[INDEFINIDO → Pregunta n]se resuelva sin ambigüedad. Las justificaciones de prioridad (media línea por condición) van en una lista dentro de la sección de análisis de riesgos, no dentro de la tabla. Completado cuando: cada condición tiene un origen declarado y cada[INDEFINIDO]tiene un número de pregunta asignado. -
Buscar hechos antes de preguntar. Separe las preguntas por destinatario. PO: comportamiento de negocio indefinido. DEV: arquitectura, observabilidad, capa de prueba, aislamiento de dependencias externas, control de tiempo, aprovisionamiento de datos de prueba, respuesta de error de API, persistencia tras fallo, idempotencia técnica. En modo código, envíe un subagente para responder preguntas DEV leyendo código: ¿la notificación es síncrona o asíncrona? ¿hay un bloqueo en la aprobación? ¿existe un mock para el sistema externo? Un hecho encontrado se convierte en resultado esperado o capa definida, con cita de la fuente. En modo sin código, la búsqueda se restringe a archivos del espacio de trabajo sin subagentes; si no se encuentra nada, indíquelo en una sola línea al inicio de la ronda 1. Completado cuando: cada pregunta está marcada como respondida por una fuente o abierta, con destinatario asignado.
-
Examinar PO. Invoque la herramienta Skill para
socratic-examination. La ronda de preguntas acompaña a la matriz actual, ya que las preguntas hacen referencia a condiciones específicas. La frontera consiste en preguntas PO, primero las bloqueantes (las que desbloquean condiciones P1), cada una con una respuesta recomendada cuando las especificaciones proporcionan fundamento; cuando está ausente, proporcione "sin recomendación" y opciones. Las respuestas de PO actualizan la matriz inmediatamente. Desafíe los términos contra el glosario, pero registre enCONTEXT.mdsolo lo que el PO resuelve. Completado cuando: la frontera de preguntas PO está vacía, o el PO solicita cerrar. -
Sintetizar. Escriba el plan siguiendo TEMPLATE.md: matriz, análisis de riesgos, escenarios P1 en Gherkin con autoverificación, auditoría de automatización, impacto de regresión basado estrictamente en la documentación del sistema existente (sin contexto, enumere preguntas de impacto para DEV), preguntas restantes por destinatario, veredicto de cobertura. Completado cuando: el archivo existe en la ruta definida por
docs/agents/refinement.mdcon el descargo de responsabilidad final presente. -
Enrutar elementos abiertos. Preguntas DEV abiertas en modo sin código y preguntas PO abiertas que no pudieron responderse: escriba un cuestionario por destinatario siguiendo
QUESTIONNAIRE.mdenrequirements-rigor, junto con el plan, y enlace los archivos desde las preguntas abiertas. Completado cuando: ninguna pregunta abierta queda sin destinatario o cuestionario. -
Reportar. Veredicto, dónde se publicó el plan, cantidad de condiciones P1 ejecutables y qué desbloquea cada cuestionario.
Aviso final
⚠️ Este resultado proporciona la línea base analítica para un plan de pruebas, no el plan de pruebas final. Las decisiones sobre cobertura, priorización y esfuerzo pertenecen al equipo de QA, con validación de PO (comportamientos indefinidos) y Dev (arquitectura y capas).