Checklist de UAT para la puesta en producción de un CRM

Antes de la UAT

La mayoría de las UAT que salen mal fallan aquí: un alcance poco claro, guiones que nadie revisó, testers sin una cuenta que funcione.

Alcance

• Acuerda qué procesos e historias de usuario entran en la UAT, y deja por escrito lo que no entra.
• Nombra para cada proceso un responsable del negocio: la persona que da el sign-off.
• Acuerda qué significan Critical, High, Medium y Low antes de registrar la primera incidencia.

Casos de prueba

• Escribe un caso de prueba por escenario de negocio, con las palabras de quienes lo prueban.
• Da a cada paso una acción y un resultado esperado, y datos de prueba cuando importen.
• Marca cada caso de prueba como Must, Should o Could, para que los importantes se prueben primero.
• Añade los caminos alternativos: un valor erróneo, un campo vacío, un usuario sin el rol adecuado.
• Comprueba que cada historia de usuario del alcance tiene al menos un caso de prueba.
• Pide a un usuario clave del negocio que revise los guiones antes de los días de prueba.

Testers

• Elige testers que hagan el trabajo a diario, de cada equipo que usa el sistema.
• Asigna a cada tester un grupo y sus propios guiones.
• Bloquea los días de prueba en sus calendarios y libéralos de su trabajo diario.
• Explícales en media hora cómo registrar un resultado y cómo registrar una incidencia.

Entorno y datos de prueba

• Prepara un entorno de prueba que se parezca a producción: configuración, integraciones y datos.
• Crea una cuenta de prueba para cada rol y comprueba que cada una puede iniciar sesión.
• Carga los datos de prueba: clientes, productos, listas de precios y registros abiertos.
• Usa datos de prueba en lugar de datos de clientes siempre que puedas.
• Acuerda cuándo se despliegan las correcciones en el entorno de prueba durante los días de prueba.

Calendario

• Planifica los días de prueba por bloques, con una hora fija para el triaje cada día.
• Reserva tiempo para una ronda de repruebas después de las correcciones.
• Fija la fecha de la reunión de go/no-go e invita ya al comité de dirección.
• Revisa el calendario de versiones de Salesforce o Dynamics 365: una versión de la plataforma en plena UAT cambia lo que pruebas.

Criterios de entrada

• La prueba de sistema ha terminado y no queda abierto ningún defecto Critical de ella.
• El entorno de prueba, las cuentas de prueba y los datos de prueba están listos.
• El negocio ha revisado los casos de prueba.
• Cada tester ha sido invitado y ha iniciado sesión una vez.

Durante la UAT

Haz que los días sean cortos y la información esté en un solo lugar, para que los problemas se encuentren, se decidan y se corrijan el mismo día.

Stand-up diario

• Empieza cada día con quince minutos: qué se ha probado, qué bloquea, qué está previsto hoy.
• Compara el avance por grupo con el plan y mueve a los testers adonde se les necesite.

Registrar incidencias

• Registra una incidencia por problema, con el paso, lo que esperabas y lo que pasó en su lugar.
• Añade una captura de pantalla y el enlace al registro.
• Busca primero una incidencia existente, para que el mismo problema no se registre dos veces.
• Asegúrate de que cada paso fallido tiene una incidencia, o un motivo por el que no la tiene.

Triaje

• Haz el triaje cada día, con el negocio y el equipo de desarrollo juntos.
• Da a cada incidencia nueva una gravedad, una prioridad y alguien que la corrija.
• Decide para cada una: corregirla, rechazarla o convertirla en una solicitud de cambio.
• Pon las solicitudes de cambio en el backlog, no en esta versión.

Repruebas

• Deja que el tester que encontró la incidencia la vuelva a probar cuando se despliegue la corrección.
• Anota en qué versión y en qué build se hizo cada reprueba.
• Empieza una ronda nueva tras una corrección grande y vuelve a probar los procesos de alrededor.

Cerrar la UAT

La UAT termina con una decisión. Tómala con hechos y deja por escrito quién decidió qué.

Criterios de salida

• Todos los casos de prueba Must han pasado.
• No hay ninguna incidencia Critical abierta.
• Cada incidencia High abierta tiene una solución provisional o una fecha de corrección que el negocio acepta.
• Cada caso de prueba del alcance tiene un resultado.

Sign-off

• Pide al responsable de cada proceso que dé su sign-off: aceptado, aceptado con condiciones o rechazado.
• Anota cada condición, con quién la cumple y para cuándo.

Go/no-go

• Haz la reunión de go/no-go con las cifras en pantalla, no de memoria.
• Registra la decisión, las condiciones y quién la tomó.

El informe

• Indica qué entraba en el alcance y qué no se probó.
• Muestra los resultados por grupo y por prioridad, y la versión y el build que se probaron.
• Enumera las incidencias abiertas por gravedad, con la decisión sobre cada una.
• Añade los sign-offs, con sus condiciones.
• Nombra los riesgos conocidos y las soluciones provisionales para las primeras semanas después de la puesta en producción.

Después de la puesta en producción

• Conserva los casos de prueba: son la prueba de regresión para la próxima versión del CRM.
• Anota qué harías de otra forma en la próxima UAT, mientras lo tienes fresco.