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.
Las dos salidas
Sección titulada «Las dos salidas»- 100 % correcto →
kb uat importarregistra la aceptación en el 07 —quién y cuándo, del archivo que devolvió el usuario, nunca tipeada— y/kb-entregacierra el requerimiento conkb finalizar, que la exige. «Entregado» lo decidekb finalizar: un 08 viejo que nacióentregadoya 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):
kb uat reabrir --hallazgo "H-01: el saldo no incluye dólares" --hallazgo "H-03: …"Qué hace la ronda de corrección
Sección titulada «Qué hace la ronda de corrección»| Pieza | Qué pasa |
|---|---|
| El 07 | La ronda queda numerada (ronda_uat: 2) — histórico de cuántas vueltas costó |
| El plan | Una tarea T-C2.1… por defecto: visible, asignable, y como subtarea en el tablero |
| La fase | Vuelve 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 rama | El PR anterior la borró al aprobarse: kb ramas la re-crea desde la cadena del pase, publicada — el mismo comando de siempre |
| El nuevo PR | Abre 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.