Workflow de Revisión de TC
Contenido
- Lista de verificación de progreso
- Disciplina
- La Ley de Hierro
- Rechazo primero (puerta de condición previa)
- Paso 1 — Cargar ambas fuentes textualmente [libertad media]
- Paso 2 — Construir la matriz de trazabilidad [libertad media]
- Paso 3 — Verificación de calidad de filas [libertad media]
- Paso 3b — Barrido de fuentes antes de «preguntar al PO/reportero» (obligatorio) [libertad baja]
- Paso 4 — Informar «Bien» vs «Requiere mejora» [libertad media]
- Paso 5 — Notificar al canal de revisión de TC del proyecto [libertad baja]
- Cierre de garantía de calidad (obligatorio antes de «hecho») [libertad baja]
- Composición de la skill
- Fuera del alcance
- DEBE / NUNCA
- Archivos de lectura obligatoria
- Dependencias
Juzga un documento de casos de prueba que alguien ya ha escrito: este workflow nunca diseña ni edita casos de prueba por sí mismo. Responde una pregunta: ¿este documento, tal como está escrito, demuestra que se verificarán los CA/CL y las reglas de negocio del ticket?
Acceso directo por comando slash (en runtimes que admiten comandos): /tc-review → commands/tc-review.md.
Lista de verificación de progreso
Copia este bloque en tu respuesta cuando comience la ejecución y marca cada línea a medida que se complete. Una puerta fallida te devuelve al paso que indica su línea Volver a: — desmarca desde allí.
Progreso de revisión de TC:
- [ ] Rechazo primero (puerta de condición previa)
- [ ] Paso 1 — Cargar ambas fuentes textualmente
- [ ] Paso 2 — Construir la matriz de trazabilidad
- [ ] Paso 3 — Verificación de calidad de filas
- [ ] Paso 3b — Barrido de fuentes antes de «preguntar al PO/reportero» (obligatorio)
- [ ] Paso 4 — Informar «Bien» vs «Requiere mejora»
- [ ] Paso 5 — Notificar al canal de revisión de TC del proyecto (preguntar solo el hilo)
- [ ] Cierre de garantía de calidad (obligatorio antes de «hecho»)
Disciplina
Sigue shared-preamble.md y shared-must-never.md.
La Ley de Hierro
NO HAY HALLAZGO SIN UNA FUENTE CITADA EN AMBOS LADOS
Cada hallazgo compara dos cosas que se abrieron realmente en esta sesión: el texto del propio documento de TC y el texto de los CA/CL/reglas de negocio del ticket (o una fuente de diseño como Figma/PRD, solo después de haberla abierto realmente). «El TC parece incompleto» desde una sensación general de calidad, sin citar las palabras del ticket al lado, no es un hallazgo: lee el ticket, luego juzga. Una afirmación sobre una fuente de diseño (texto de copia exacto, estado de UI exacto) sin una fuente realmente abierta en esta sesión tampoco es un hallazgo: di «no verificado – no se pudo abrir {fuente}» en lugar de adivinar.
Esta es la misma disciplina que ejecuta catch-ai-workflow para trabajos finalizados en general; este workflow es su instancia específica de TC, ejecutada antes de la ejecución en lugar de después.
Rechazo primero (puerta de condición previa)
NO DEBE iniciarse sin ambos:
- el documento de TC — una hoja, CSV o archivo markdown, accesible y legible en esta sesión;
- el ticket correspondiente — una clave de issue de Jira o URL que contenga CA/CL (o una fuente de especificación equivalente que el usuario nombre explícitamente).
🔴 DETENER — si falta alguno, detente en un mensaje según skill-rules-style.md.
Ticket entre organizaciones / sitios: si el ticket reside en un sitio de Atlassian al que el MCP conectado no tiene acceso, indícalo y pide al usuario que conceda acceso (o que pegue los CA/CL directamente) — nunca adivines un id de cloud, nunca recurras a un inicio de sesión de navegador para leerlo.
Paso 1 — Cargar ambas fuentes textualmente [libertad media]
- Documento de TC — léelo tal cual es; no reescribas, resumas ni «limpies» la redacción al cargarlo. Anota la fuente exacta (id de la hoja + tab/gid, ruta de archivo o URL) para que cada cita posterior pueda apuntar a ella.
- Ticket — obtén CA, CL y cualquier sección de reglas de negocio / lista de re-verificación de los campos propios del ticket (descripción, campos personalizados — algunos proyectos mantienen el contenido fuera de
descriptionpor completo; verifica ambos). Cita las etiquetas de CA/CL y el texto exactamente como están escritos; nunca parafrasees de memoria de un ticket similar. No se encuentran CA/CL en ninguno de los dos lugares → detente según la puerta de rechazo primero. Se encuentra texto de especificación pero sus elementos no tienen etiquetas de CA/CL → 🔴 DETENER — muestra el texto encontrado y pide al usuario cómo numerarlos antes del Paso 2; nunca inventes etiquetas. El ticket o el documento de TC arrojan error, se agota el tiempo de espera o devuelven contenido parcial (texto truncado, campos faltantes, pestañas que no cargan) → informa al usuario el error exacto o lo que falta, no construyas la matriz a partir de CA/CL parciales o un documento de TC parcial, entrega el fallo asuperpowers:systematic-debuggingy reanuda el Paso 1 solo cuando se cargue el texto completo. - Si se enlaza una fuente de diseño (Figma, PRD) y el usuario desea una verificación cruzada, ábrela en esta sesión. Si no se puede abrir (sin sesión, sin acceso, solo vista sin contenido renderizado), regístralo claramente — se convierte en una nota de «no verificado» junto a cualquier hallazgo relacionado, nunca una omisión silenciosa.
Paso 2 — Construir la matriz de trazabilidad [libertad media]
Para cada CA y CL del ticket, enumera qué fila(s) de TC afirman cubrirlo:
| CA/CL | Afirmado por | Estado |
|---|---|---|
CA_01 | TC_003 | cubierto |
CA_05 | — | sin TC — brecha |
CA_02 | TC_007 | etiquetado incorrecto — TC_007 Resultado Esperado coincide con CA_04 |
CL_01 | TC_010, TC_011 | etiqueta inconsistente — el TC_012 hermano prueba el mismo elemento sin etiqueta |
El estado es una lista cerrada — usa exactamente uno de estos cuatro valores por fila, nombrando los ids como se muestra:
cubierto · sin TC — brecha · etiquetado incorrecto — <TC> coincide con <CA/CL> · etiqueta inconsistente — <ids de TC>.
Una fila con varios problemas toma el primero que aplique en ese orden después de cubierto. Un agujero en la propia lista de CA del ticket es una brecha a nivel de especificación, no una fila de la matriz — repórtalo bajo «Requiere mejora» como una pregunta de especificación (ver DEBE / NUNCA).
Los CA/CL tachados no cuentan. Una fila que el ticket ha tachado (p. ej. -CA_07-, a menudo marcada como duplicada) está fuera del alcance: déjala fuera de la matriz y fuera del informe por completo. No la menciones, ni siquiera como «correctamente no cubierto».
Las reglas de negocio y los comentarios del ticket son contexto, no CA adicionales. Léelos para entender lo que significa un CA/CL y úsalos para juzgar si un TC prueba lo correcto. Reporta un elemento de regla de negocio o comentario solo cuando entre en conflicto con un CA/CL, y nombra el CA/CL que contradice. Una regla o comentario que no tiene TC pero no contradice ningún CA/CL no es un hallazgo. Déjalo fuera de «Requiere mejora» y no añadas una sección de «notas de especificación» para ello.
Señala, con los ids de fila/CA nombrados:
- un CA/CL con cero TC;
- un TC cuyo Resultado Esperado coincide verificablemente con un CA diferente al que está etiquetado;
- el mismo tema (p. ej., un elemento de UI compartido) etiquetado de forma inconsistente entre filas hermanas — algunas llevan un CA, otras no, sin una razón indicada.
Paso 3 — Verificación de calidad de filas [libertad media]
Aplica tc-quality-standards.md a cada fila, leyendo para estas formas específicas de fallo de revisión (distintas de la calidad de autoría — esto trata sobre un documento escrito por otra persona, por lo que la pregunta es si se puede confiar, no si es elegante):
| Señal | Por qué importa |
|---|---|
| Los pasos no alcanzan el estado que afirma el título. Una fila titulada «El alumno ve X» cuyos pasos se detienen en la página principal nunca abre X. | El caso no puede verificar lo que dice que verifica. |
| El Resultado Esperado es la propia frase del CA, copiada textualmente, sin descomposición. Cuando el ticket enumera varios subelementos concretos (campos, estados, variantes de botón) bajo ese CA, un Resultado Esperado que solo repite la frase del CA no le da al evaluador nada que verificar fila por fila. | Aprobado/reprobado se convierte en una suposición. |
| El CA enumera casos/estados nombrados (p. ej., «caso 1–6», estados de «carga / vacío / filtro») y el documento tiene una fila genérica para todos ellos. | La mayoría de los estados enumerados quedan sin probar aunque la fila esté marcada como hecha. |
| Los Datos de Prueba no tienen un valor concreto donde el CA lo necesita (un conteo límite, una relación de fecha específica, una opción de filtro nombrada). | La fila no puede ejecutarse tal como está escrita — el evaluador tendría que inventar el valor faltante. |
| La fila prueba una condición diferente a la redacción del CA. El CA dice «ya se ha desplazado más allá» pero la fila usa «visto hasta el final». El CA dice «solo elementos publicados» pero el Resultado Esperado nunca verifica el estado. | La fila puede pasar mientras la condición del CA permanece sin probar. |
| El Resultado Esperado es más vago de lo que permiten los Datos de Prueba de la propia fila. Los Datos de Prueba proporcionan todas las entradas necesarias para calcular la respuesta (puntuaciones, conteos, una fórmula), pero el Resultado Esperado solo dice «ordenado correctamente». | El evaluador tiene que deducir el valor esperado sobre la marcha, por lo que un orden incorrecto aún puede marcarse como aprobado. |
| Las columnas de la fila se contradicen entre sí. La Precondición dice «4 elementos» pero los Datos de Prueba enumeran 3. El título dice «estado» pero el Resultado Esperado solo verifica el orden. | Cualquiera que sea la columna que siga el evaluador, la otra está equivocada. |
| Falta una Precondición del ticket en todas las filas (p. ej., «el usuario ha iniciado sesión»). | Cada fila hereda un paso de configuración no indicado. |
| La configuración nombra un método sin proporcionarlo («hay una forma de hacer que la solicitud falle», «preparar datos suficientes»). | Dos evaluadores lo configurarán de dos maneras diferentes. |
No señales elecciones de estilo de casos de prueba que no afecten si se puede confiar en el caso (convención de nombres, orden de columnas, etiquetas de prioridad) a menos que el usuario pida específicamente una revisión de estilo. Esto anula aquí tc-quality-standards.md: ignora su atributo de Prioridad y su línea de puerta de revisión «Prioridades asignadas» a menos que el usuario solicite una revisión de estilo.
Paso 3b — Barrido de fuentes antes de «preguntar al PO/reportero» (obligatorio) [libertad baja]
Este workflow nunca decide un veredicto de producto, pero sí plantea brechas y preguntas a nivel de especificación. Antes de que cualquier hallazgo se convierta en «preguntar al PO/reportero» o «especificación poco clara», ejecuta el barrido de fuentes en la capa 14 de result-quality-gate.md: el código del producto en la rama predeterminada con path:line, sus comentarios en línea y git log -L / blame; el ticket principal y todos los comentarios; los tickets circundantes (padre / épica, vinculados, hermanos en la misma pantalla o API, y tickets que nombran los mensajes de commit); los resultados de regresión; y el nodo de diseño. Cita lo que se leyó junto al hallazgo. Una pregunta que las fuentes ya responden es un hallazgo con su fuente, no una pregunta.
Clon de producto faltante o ilegible (la verificación {MONOREPO} en dependencies.md falla): no detengas la revisión ni omitas la capa de código en silencio. Escribe código no verificado — sin clon junto a cada pregunta que la capa de código habría respondido, continúa el barrido con las fuentes restantes y nunca presentes dicha pregunta como barrido completo — va al Paso 4 con esa nota.
Salida por elemento: el hallazgo (o la pregunta restante) + la fuente citada con su ubicación (path:line, clave del ticket + comentario, fila de regresión, nodo de diseño), o la nota código no verificado — sin clon cuando la capa de código no pudo ejecutarse.
Volver a: Una pregunta que el barrido responde regresa al Paso 2 o 3 como un hallazgo con fuente; solo una pregunta que ninguna fuente responde va al Paso 4 como «confirmar con dev/PO».
Paso 4 — Informar «Bien» vs «Requiere mejora» [libertad media]
Dos listas breves, cada viñeta anclada a un id de fila, id de CA o texto citado — nunca una opinión sin anclar.
**Bien**
- {hallazgo, con id de TC/CA o cita}
**Requiere mejora**
- {hallazgo, con id de TC/CA o cita}
→ Sugerencia: {cómo solucionarlo}
Cada viñeta de «Requiere mejora» lleva una línea «→ Sugerencia:» que indica cómo solucionarlo. Un problema sin solución deja al autor de TC adivinando. Cada sugerencia debe provenir de una fuente, nunca de un valor inventado:
- Calculado a partir de los datos de la propia fila: cuando los Datos de Prueba ya contienen las entradas, calcula el valor y entrégalo (p. ej., el orden esperado con cada puntuación calculada). Muestra los números para que el autor pueda verificarlos.
- Tomado de la redacción del CA/CL: p. ej., reemplaza la condición incorrecta con la propia frase del CA, o añade la cláusula faltante del Resultado Esperado usando el texto del propio CA.
- Ninguna fuente da el valor (un umbral, un conteo o un tiempo que el ticket nunca indica): sugiere añadir el valor y di quién lo confirma («confirma el conteo con dev/PO»). Nunca inventes un número.
Mantén cada viñeta concisa. La sugerencia dice qué cambiar, no una fila reescrita. Si el usuario pide reducir el alcance (p. ej., «elimina todo sobre X»), regenera la lista a partir de los Pasos 2–3 con esa categoría eliminada — no edites la prosa de forma reactiva, ya que de lo contrario la misma categoría reaparecerá con diferente redacción la próxima vez.
Idioma: por defecto, usa el idioma del ticket / documento de TC. Mixto = los CA/CL del ticket y el documento de TC están escritos en diferentes idiomas → pregunta al usuario una vez en qué idioma escribir la revisión. Los menús de Helix y las preguntas de ingreso permanecen en inglés según user-communication.md; el contenido de la revisión sigue el idioma del documento de destino, la misma excepción que ya lleva ese documento.
Publica la revisión en el chat antes del envío del Paso 5 — un mensaje externo no se puede deshacer como un mensaje de chat. La pregunta del hilo del Paso 5 es la señal de inicio; no añadas una pregunta separada de «¿lo envío?».
Paso 5 — Notificar al canal de revisión de TC del proyecto [libertad baja]
Cada ejecución envía la revisión finalizada al canal de revisión de TC del proyecto. Pregunta al usuario solo en qué hilo publicarla (proporciona el enlace al hilo si está disponible). No preguntes si debe enviarse; la revisión ya está lista.
Cierre de garantía de calidad (obligatorio antes de «hecho») [libertad baja]
- No hay hallazgos huérfanos — cada viñeta de «Requiere mejora» tiene una línea
→ Sugerencia:. Cada sugerencia tiene una fuente (calculada, CA/CL, o «confirma con dev/PO»). - Cada cita se puede rastrear — cada cita de
{source}apunta a una fila del documento de TC o a un texto de CA/CL del ticket abierto en esta sesión. Ninguna cita inventa texto de un ticket no abierto. - Brechas de CA/CL vs brechas de especificación — una brecha donde el ticket carece de un CA para algo que las filas de TC mencionan se reporta como pregunta de especificación, no como fila faltante. Confirmado en el informe.
- No hay etiquetas inventadas — si el ticket no daba etiquetas a sus CA y el usuario las proporcionó en el Paso 1, las etiquetas del informe coinciden con las que el usuario dio. No se inventaron prefijos
AC_sin la dirección del usuario. - No hay reglas de negocio huérfanas — ningún elemento de regla de negocio/comentario aparece como hallazgo a menos que contradiga un CA/CL. Confirmado.
- Lista de verificación de progreso completa — cada línea está marcada, incluyendo el cierre de GC.
- Se preguntó el hilo — la pregunta del hilo del Paso 5 se hizo y se usó la respuesta.
Si algo falla, vuelve al paso que lo corrige; nunca marques «hecho» con fallos abiertos del cierre.
Composición de la skill
Este workflow, por diseño, nunca redacta un nuevo caso de prueba, nunca edita un caso de prueba existente (ni siquiera para «arreglar» algo que encuentra), y nunca ejecuta un caso de prueba. Se basa en:
- tc-quality-standards.md — estándares de calidad de casos de prueba
- shared-preamble.md — preámbulo compartido
- shared-must-never.md — reglas compartidas DEBE/NUNCA
- result-quality-gate.md — puerta de calidad de resultados para el barrido de fuentes
- user-communication.md — reglas de comunicación con el usuario
- skill-rules-style.md — estilo de reglas de skill
Ejecuta como entrada principal: el comando /tc-review.
Fuera del alcance
| Caso de uso | Workflow correcto |
|---|---|
| Redactar nuevos casos de prueba desde cero | tc-fe-prep-workflow / tc-api-prep-workflow |
| Ejecutar un ticket | testing-ticket-workflow |
| Revisar evidencia grabada de una ejecución | review-result-workflow |
| Volver a probar una corrección de bug | retest-bug-workflow |
DEBE / NUNCA
DEBE:
- Citar tanto la fuente del TC como la del ticket para cada hallazgo.
- Preguntar solo el hilo al final (nunca «¿debería enviarse esto?»).
- Usar las etiquetas de CA/CL tal como aparecen en el ticket; si el ticket no tiene etiquetas, preguntar al usuario cómo numerarlas.
- Ejecutar el barrido de fuentes antes de cualquier hallazgo de «especificación poco clara».
- Incluir una línea «→ Sugerencia:» para cada viñeta de «Requiere mejora».
NUNCA:
- Inventar etiquetas AC/EC/CA/CL ni numeración.
- Adivinar un id de cloud de Atlassian ni iniciar sesión a través del navegador para leer un ticket.
- Detener el workflow por un clon de producto faltante — continuar con otros chequeos.
- Incluir CA/CL tachados en la matriz o en el informe.
- Informar reglas de negocio o comentarios como hallazgos a menos que contradigan un CA/CL.
- Reescribir ni editar el documento de TC.
- Redactar nuevos casos de prueba.
Archivos de lectura obligatoria
- tc-quality-standards.md
- shared-preamble.md
- shared-must-never.md
- result-quality-gate.md
- user-communication.md
- skill-rules-style.md
- dependencies.md (para la verificación de
{MONOREPO})
Dependencias
- Acceso a la API de Jira (a través del MCP de Atlassian) o a una fuente de especificación equivalente.
- Capacidad de leer documentos: hojas de cálculo (ids + gids), CSV (rutas de archivo), markdown (rutas de archivo).
- (Opcional) Clon del repositorio de producto para el barrido de fuentes.
- Canal de Slack/Teams «TC-review» del proyecto (o equivalente) y acceso de bot para publicar.
- MCP de Atlassian con alcance para leer el ticket objetivo (nunca adivinar un id de cloud).