User Acceptance Testing (UAT)
Si un sistema técnicamente correcto es, además, el que el negocio necesita — quién ejecuta UAT y en qué se diferencia de testing de sistema.
Qué es
UAT verifica que el sistema sea aceptable para sus usuarios o stakeholders de negocio. Su pregunta central no es “¿el código funciona?”, sino:
¿El sistema resuelve correctamente la necesidad de negocio?
Este es exactamente el escenario de validación que mencionamos en el primer artículo de este tema: ReservaResto puede crear la reserva, cobrar la seña y bloquear la mesa de forma técnicamente impecable, y UAT puede descubrir igual que la política de no-show que implementamos —por ejemplo, cobrar el 50% de la seña pasadas 24 horas— no refleja cómo el restaurante realmente quiere manejar a un cliente que falta reiteradas veces.
Quién lo ejecuta
Normalmente participan business stakeholders, product owners, domain experts, y en el caso de ReservaResto, los dueños o encargados de los restaurantes que van a usar el producto todos los días. Como Software Engineers podemos colaborar preparando los escenarios y la infraestructura necesaria, pero el criterio de aceptación debería representar la necesidad real del negocio, no la nuestra.
UAT vs. Testing de sistema
| Pregunta | |
|---|---|
| Testing de sistema | ¿El sistema completo se comporta según sus especificaciones? |
| UAT | ¿Ese comportamiento es aceptable para los usuarios y el negocio? |
Ambos pueden usar escenarios muy parecidos —el mismo flujo de reserva y cancelación—, pero tienen criterios de éxito distintos: uno mira la especificación, el otro mira si esa especificación era la correcta.
Del testing funcional al no funcional
El testing funcional nos permite verificar que el sistema hace lo que debe hacer. Pero que el comportamiento sea correcto no garantiza que el sistema sea adecuado en las condiciones reales de uso. El foco pasa entonces a qué tan bien cumple esas funciones, comenzando por el performance testing.