Revisa una entrega de Taiga con pruebas

Empieza por el resultado de la iniciativa

El servicio ficticio de equipamiento permite ahora que los empleados vean sus propias solicitudes. Empieza la revisión por el resultado y el alcance de la iniciativa. Identifica qué debe cumplirse y qué debe mantener intacto el cambio.

En esta entrega, un empleado no debe poder leer la solicitud de otro. Los responsables deben conservar su acceso definido. Una prueba que solo abra la página no demuestra ninguna de las dos condiciones.

Conecta los registros

La página Runs registra los intentos, incluidos los fallidos. Cada ejecución identifica el plan que ejecutó. Una página de ejecución es un registro para inspección; las decisiones que cambian el trabajo pertenecen a la iniciativa.

Lee las pruebas de cada paso sobre pruebas de software y formato. Taiga hace visibles las comprobaciones fallidas o no ejecutadas. No conviertas «no ejecutada» en «superada» en tu resumen de revisión.

Examina las suposiciones y los límites

Busca suposiciones sobre el modelo de acceso, el esquema, el entorno y los servicios externos. Compáralas con la intención publicada y el código real.

Para el servicio de equipamiento, examina dónde se comprueba quién es el propietario de la solicitud. Prueba una solicitud autorizada, una de otro empleado y una inexistente. Comprueba que los logs no revelen contenido confidencial de las solicitudes.

Revisa también los cambios en las pruebas. Un resultado correcto tiene poco valor si el cambio eliminó la aserción que detectaría el defecto. Incluye los cambios en flujos de trabajo y configuración de pruebas dentro del alcance de la revisión.

Da comentarios que permitan actuar

Identifica el comportamiento, el resultado esperado y las pruebas necesarias. Por ejemplo: «El endpoint comprueba el inicio de sesión, pero no la propiedad de la solicitud. Añade la comprobación de acceso en el servidor y una prueba con la solicitud de otro empleado».

Taiga puede responder a comentarios de revisión de pull requests y a comprobaciones fallidas con cambios en la misma rama. Después de las actualizaciones, examina el nuevo commit y sus comprobaciones. Las pruebas anteriores pueden no cubrir un artefacto modificado.

Si la ejecución se detuvo porque el plan estaba incompleto o se debilitó una comprobación, lee el motivo indicado. No retires el estado de borrador solo porque el resumen visible de comprobaciones esté en verde.

Toma la decisión de aceptación correcta

Registra qué criterios están verificados y cuáles siguen sin resolverse. Deja que las revisiones y comprobaciones obligatorias del repositorio apliquen el límite del merge. Conserva cualquier decisión de publicación separada.

Taiga observa los despliegues que realiza tu pipeline. Verifica el entorno y el artefacto antes de decir a los usuarios que el cambio está disponible. Un despliegue fallido puede dejar la versión anterior correcta atendiendo el tráfico.

Completa el resultado con una comprobación del servicio: el empleado puede usar la función, el acceso no autorizado se deniega y el responsable operativo puede observar los fallos. Continúa con la gestión de una interrupción.