Saltearse al contenido

La UAT y las rondas de corrección

El orden real de un requerimiento no termina en el Pull Request: el PR se aprueba, se publica a staging, y ahí recién prueba el usuario final. Los resultados llegan mucho después del PR — y el ciclo lo sabe.

kb init → fases 1–4expediente, plan, compuertas Implementacióntareas T-NN (y T-C en rondas) kb pruebasE01 · E03 · E04 kb publicarel wiki queda al día kb pr → PR aprobadohoja de aprobación + wiki Deploy a stagingpipeline del equipo UAT del usuariolos resultados llegan después Defectos H-NNkb uat reabrir --hallazgo 100 % correctoaceptación al 07 Ronda N abiertaT-C al plan · fase atrás Entrega/kb-entrega · cierre ↻ el ciclo se repite completo; el nuevo PR dice «ronda N»
  • 100 % correcto → kb uat importar registra la aceptación en el 07 —quién y cuándo, del archivo que devolvió el usuario, nunca tipeada— y /kb-entrega cierra el requerimiento con kb finalizar, que la exige. «Entregado» lo decide kb finalizar: un 08 viejo que nació entregado ya no da el expediente por entregado en ningún lado.
  • Defectos → el requerimiento no terminó. Tras clasificar los hallazgos con /kb-uat (defecto · requerimiento nuevo · duda de uso · ambiente):
Ventana de terminal
kb uat reabrir --hallazgo "H-01: el saldo no incluye dólares" --hallazgo "H-03: …"
PiezaQué pasa
El 07La ronda queda numerada (ronda_uat: 2) — histórico de cuántas vueltas costó
El planUna tarea T-C2.1… por defecto: visible, asignable, y como subtarea en el tablero
La faseVuelve a implementación en todos los documentos que ya la habían pasado — sin eso, la compuerta de rama no regiría en la corrección
La ramaEl PR anterior la borró al aprobarse: kb ramas la re-crea desde la cadena del pase, publicada — el mismo comando de siempre
El nuevo PRAbre diciendo «🔄 Ronda de corrección UAT N» — el revisor sabe que revisa correcciones, y las T-C dicen qué hallazgo corrige cada cambio

Solo los defectos reabren. Lo clasificado como requerimiento nuevo sale del alcance y va a su propio ticket — es lo que evita que el requerimiento no cierre nunca porque el usuario sigue agregando cosas.

La validación del usuario empieza con el PR aprobado

Sección titulada «La validación del usuario empieza con el PR aprobado»

Los resultados de las pruebas automatizadas son de la fase 6 (07 §1, los escribe kb pruebas resultados); la validación del usuario de negocio es la fase 7 (07 §3 en adelante) y ocurre después de que el revisor aprueba el PR y el cambio se publica en staging. Al terminar las pruebas automáticas no se le pide nada al usuario: sigue /kb-revisar → /kb-pr. kb plan-uat se niega mientras el PR esté abierto o con cambios pedidos, y después de una ronda de corrección hasta que se apruebe el PR de lo corregido (--forzar lo salta y queda registrado), y el ciclo marca la fase 7 como «recién después de kb pr aprobado».

kbspec es un producto de Kabata Soft contacto@kabatasoft.com © 2026 Kabata Soft S.A. Todos los derechos reservados.