Por qué el UAT falla incluso cuando parece exitoso
En muchos ciclos de UAT, todos los escenarios se marcan como aprobados, y dos semanas después del lanzamiento, se abren decenas de solicitudes. Esto no es una paradoja, es un resultado directo de una prueba construida en torno a las pantallas.
Una prueba centrada en la pantalla pregunta: "¿Es posible crear un registro?". Una prueba centrada en el proceso pregunta: "¿Puede un agente recibir una solicitud, identificar que el cliente existe con otro nombre, verificar su elegibilidad en el sistema central, abrir un caso, transferirlo a otra entidad y cerrarlo, incluso cuando el cliente existe dos veces en el sistema?". El segundo escenario encuentra lo que el primero omite.
Esta guía presenta la estructura de UAT que se enfoca en la segunda pregunta. La conexión con otras fases del proyecto se encuentra en la Guía de Implementación de Salesforce.
Qué debe estar listo antes de empezar
- Un entorno estable que no reciba despliegues durante el ciclo, excepto por correcciones de bloqueo aprobadas.
- Datos de prueba con un volumen y complejidad similares a los de producción.
- Usuarios con permisos reales, no administradores para todos. La mitad de los problemas de permisos se descubren solo cuando el evaluador tiene el perfil correcto.
- Criterios de aceptación definidos para cada proceso central.
- Un mecanismo único de reporte de errores, con campos obligatorios mínimos.
El elemento que más se suele omitir es el tercero, y es el que genera los errores más embarazosos el día del lanzamiento.
Cómo construir un escenario que encuentre problemas
Un buen escenario comienza con una persona y un estado inicial, no con un clic. Una estructura que funciona:
- Quién - Rol y permiso exactos.
- Estado inicial - Qué información existe en el sistema antes de que comience el escenario.
- Qué sucede - El evento de negocio que activa el proceso.
- Qué hace el evaluador - A nivel de acción de negocio, no a nivel de clic.
- Resultado esperado - Incluyendo lo que sucedió en otros sistemas.
- Qué no debería suceder - El registro no se expone a quien no debe, la alerta no se envía dos veces.
El sexto punto es lo que separa una lista de verificación de una prueba profesional.
Seis familias de escenarios que deben incluirse
| Familia | Ejemplo de escenario | Qué revela |
|---|---|---|
| Ruta positiva | Proceso completo de principio a fin | Si el proceso es factible |
| Excepción de negocio | Cancelación, reembolso, volver a una etapa anterior | Lógica construida solo en una dirección |
| Datos con problemas | Cliente duplicado, nombre en hebreo y español, campo vacío | Mapeo y limpieza insuficientes |
| Permisos | Usuario que intenta acceder a un registro de otra unidad | Lagunas en el modelo de exposición |
| Fallo de integración | El sistema de destino no está disponible | Manejo de errores, bucles, duplicidades |
| Volumen | Acción colectiva sobre un gran número de registros | Limitaciones de rendimiento y automatización |
La ausencia de una familia completa de la lista es una señal de que la prueba proporcionará una falsa sensación de seguridad.
Clasificación de la severidad: la condición para gestionar el ciclo
Sin una clasificación acordada, cada error parece urgente y la decisión sobre el lanzamiento se convierte en una discusión. Un modelo de cuatro niveles es suficiente:
| Nivel | Definición | Impacto en el lanzamiento |
|---|---|---|
| Bloqueador | No se puede completar un proceso central, no hay solución alternativa | Bloqueador |
| Grave | El proceso es posible con una solución alternativa pesada o se guardan datos incorrectos | Bloqueador a menos que se apruebe explícitamente |
| Medio | Inconveniente significativo, solución alternativa razonable | No bloqueador, entra en el plan de corrección |
| Bajo | Texto, orden de campos, mejora | Se recopila para la siguiente fase |
La regla importante: la clasificación la determina el propietario del proceso junto con el equipo técnico, no quien informó del error.
Condiciones para pasar a producción
Se formulan antes de que comience el ciclo y no al final:
- Cero errores bloqueadores abiertos.
- Todo error grave cerrado o aprobado por escrito con una solución alternativa y un tiempo de corrección.
- Todos los procesos centrales ejecutados en un segundo ciclo sin nuevos fallos.
- Los propietarios del proceso han aprobado por escrito.
- Existe un plan de reversión probado, no solo escrito.
Ejemplo ilustrativo: Fondo de pensiones
El escenario es hipotético y está diseñado para ilustración. Un fondo de pensiones probó un proceso de gestión de solicitudes de afiliados. El primer ciclo de UAT se completó casi en su totalidad. El equipo notó que todos los evaluadores usaron un perfil extendido, porque la asignación de perfiles precisos se había retrasado.
En un segundo ciclo, con los perfiles reales, se encontraron once errores: los agentes no veían registros de afiliados que habían sido transferidos entre planes, un botón de aprobación de excepción aparecía para quienes no estaban autorizados, y un informe de cargas devolvía resultados parciales a los jefes de equipo. Ninguno de los errores estaba relacionado con la funcionalidad probada en el primer ciclo; todos estaban en el modelo de exposición.
La conclusión práctica que se adoptó allí: no se inicia un ciclo de UAT antes de que todos los participantes tengan el perfil con el que trabajarán en producción.
Errores de gestión que encarecen el ciclo
- Despliegue de versiones en medio del ciclo, lo que invalida la validez de las pruebas ya realizadas.
- Evaluadores que informan en WhatsApp y correo electrónico en paralelo al sistema de seguimiento.
- Escenarios escritos a nivel de clic, lo que convierte cualquier cambio en la interfaz en una actualización de la documentación.
- Acortamiento del segundo ciclo por presión de tiempo, este es el ciclo que descubre las regresiones.
Estos patrones aparecen junto con otros fallos en la Guía de Errores Comunes, y la responsabilidad de cada uno de ellos se define en la Guía de Roles del Equipo de Proyecto de Salesforce.
Cuando se trata de reemplazar un sistema existente
En un proyecto de reemplazo, UAT tiene un segundo papel: la comparación. Los mismos diez escenarios se ejecutan en ambos sistemas, y los resultados se comparan campo por campo. Esta es la herramienta más eficaz para descubrir inconsistencias de mapeo antes de que se conviertan en lagunas de confianza. El orden de las operaciones en tal transición se detalla en la Guía para Reemplazar su CRM por Salesforce.
Lo que queda después del ciclo
Los escenarios de UAT no son un documento de una sola vez. Son la base para las pruebas de regresión en cada lanzamiento futuro, y son la mejor fuente de material de capacitación, ya que están escritos en el lenguaje del proceso y no en el del sistema. Guardarlos en un formato que pueda ejecutarse nuevamente es la inversión más económica que se puede hacer de cara al próximo año.