Dynamics 365 UAT: guía práctica

Cuándo necesitas una UAT en Dynamics 365

Una prueba de aceptación de usuario responde a una pregunta: ¿puede el negocio hacer su trabajo con esta versión de Dynamics 365? Lo prueban las personas que hacen el trabajo, con sus propias palabras, antes de que llegue a producción. La necesitas en estos momentos.

• Una puesta en producción. El primer Dynamics 365 Sales o Customer Service, o una migración desde otro CRM.
• Una nueva aplicación o un nuevo módulo. Customer Service junto a Sales, una nueva aplicación basada en modelos para un equipo, un portal de clientes o funciones de Copilot que activas.
• Un gran cambio. Una nueva integración con el ERP o una nueva forma de enrutar los casos.
• Las actualizaciones de Microsoft. Microsoft ya no agrupa los cambios de Dynamics 365 en dos oleadas de lanzamiento al año. Las nuevas funciones y los cambios llegan durante todo el año. Los planes de lanzamiento se archivaron en octubre de 2026; lo que viene está ahora en la hoja de ruta de Microsoft, en aka.ms/AIatWorkRoadmap. Cualquier actualización puede cambiar cómo funciona tu sistema, aunque tú no hayas cambiado nada.

Una puesta en producción necesita una UAT completa. Las actualizaciones necesitan una prueba de regresión más corta de los procesos que más importan, con un ritmo fijo. Más sobre esto en Después de la puesta en producción.

Entornos

Nunca pruebes en producción. En el Centro de administración de Power Platform, cada entorno tiene un tipo. Para una UAT quieres un sandbox.

Una copia de producción

Lo más cercano a la realidad es una copia de producción en un entorno sandbox. Al copiar un entorno, eliges qué se copia:

• Todo: las personalizaciones, el esquema y todos los datos. Lo más cercano a producción, pero contiene datos reales de clientes y todos los registros que crearon tus usuarios.
• Solo personalizaciones y esquemas: la configuración sin los datos. Después cargas tus propios datos de prueba.

Una copia sustituye lo que hay en el entorno de destino, así que hazla antes de la UAT, nunca durante. Después, apunta las integraciones y los flujos de Power Automate a sistemas de prueba, no a producción, comprueba los buzones y saca el entorno del modo de administración cuando esté listo.

Soluciones y la build

Los cambios del proyecto llegan al entorno de UAT como soluciones. Impórtalas como soluciones administradas, mediante una canalización si tienes una, para que el entorno de UAT reciba exactamente lo que recibirá producción más adelante.

• Acuerda cuándo se importan soluciones mientras se sigue probando, por ejemplo una vez al día después del triaje. Una importación en plena prueba puede cambiarle la pantalla a un tester mientras trabaja.
• Anota qué soluciones y qué versiones hay en el entorno de UAT. El número de versión de una solución es la build que pruebas, y cada incidencia y cada nueva prueba pertenecen a una.

Datos de prueba

Los testers pierden horas cuando los datos no están listos. Prepáralos antes del primer día de prueba:

• Cuentas y contactos para cada tipo de cliente que pruebas, con el propietario y la unidad de negocio correctos.
• Productos y listas de precios. Un producto necesita un elemento de lista de precios antes de poder añadirse al precio correcto, y hay que publicarlo antes de que los comerciales puedan usarlo. Comprueba que está la lista de precios de cada equipo de ventas.
• Colas, SLA y artículos de conocimientos para Customer Service: las colas a las que se enrutan los casos, SLA activos y artículos publicados que encontrar.
• Registros abiertos con los que trabajar: leads, oportunidades en distintas fases y casos abiertos.
• Nada de datos personales reales siempre que puedas evitarlo. Una copia con Todo los contiene todos, así que enmascara o anonimiza lo que los testers no necesitan ver.

Roles de seguridad, unidades de negocio y usuarios por rol

Una UAT demuestra que cada rol puede hacer su trabajo, y solo su trabajo. En Dynamics 365 eso depende de los roles de seguridad, la unidad de negocio y los equipos de un usuario. Las aplicaciones también se comparten mediante roles de seguridad: sin el rol adecuado, un usuario ni siquiera ve la aplicación.

• Haz una lista de los roles que pruebas, como un comercial, un director de ventas, un agente de servicio y un supervisor de servicio, con su unidad de negocio.
• Da a cada tester un usuario con exactamente ese rol en el entorno de UAT. Cada usuario necesita una licencia, también en un sandbox.
• Cuando una persona prueba varios roles, usa un usuario de prueba distinto por rol, o cambia el rol entre pruebas y anota cuál se usó.
• Nunca pruebes con el rol Administrador del sistema. Lo ve todo y puede hacerlo todo, así que oculta justo los problemas que una UAT debería encontrar.

Qué contar a los testers sobre el entorno

• La dirección del entorno de UAT. El marcador habitual abre producción.
• Qué aplicación abrir, como Sales Hub o Customer Service workspace, y con qué cuenta iniciar sesión.
• Que los datos son datos de prueba: nada de lo que hagan llega a un cliente real, y nada de lo que vean está al día.
• A quién llamar cuando no puedan iniciar sesión o no vean la aplicación.

En UAT StudioCada tester tiene un Test role, como el rol de seguridad, y una Test account, que aparecen en la parte superior de sus pruebas como Log in as …. Las Notes for testers contienen la dirección del entorno, los buzones de prueba y a quién llamar. Los testers inician sesión en UAT Studio con un código por correo o con Sign in with Microsoft.

Casos de prueba a partir de historias de usuario y procesos

Parte de los procesos del negocio, no de las tablas de Dataverse. Dos procesos cubren la mayor parte de una UAT de Dynamics 365:

• Del lead a la oportunidad y al presupuesto. Entra un lead y se califica en una cuenta, un contacto y una oportunidad. La oportunidad sigue el flujo de proceso de negocio, recibe productos de la lista de precios, se crea un presupuesto, se aprueba y se activa, y el acuerdo se gana y pasa al siguiente equipo o sistema.
• Gestión de casos. Un caso entra por correo o por el portal, se enruta a la cola o al agente adecuados, sigue su SLA, se soluciona con un artículo de conocimientos, se escala cuando hace falta y se resuelve.

Divide cada proceso en casos de prueba de un solo escenario de negocio cada uno, como Calificar un lead con una cuenta existente. Después comprueba que cada historia de usuario del alcance tiene al menos un caso de prueba.

Flujos de proceso de negocio

Un flujo de proceso de negocio guía a los usuarios por fases, con pasos que pueden ser obligatorios antes de la siguiente fase. Pruébalo como lo hace un usuario:

• Cada fase, y qué pasa cuando un paso obligatorio está vacío.
• Cada rama y cada rol: un flujo se puede activar solo para algunos roles de seguridad.

Enrutamiento, SLA y conocimientos

En Customer Service, gran parte del trabajo ocurre sin un clic. Prueba lo que el sistema debería hacer por sí solo: un correo se convierte en un caso de la cuenta correcta, el caso llega a la cola correcta, el SLA muestra el tiempo correcto y avisa antes de que venza, y el agente encuentra el artículo de conocimientos adecuado.

Pasos que entienden los testers de negocio

Escribe cada paso como una acción y un resultado esperado, con las palabras del tester. Añade datos de prueba donde importen. Un tester nunca debería tener que adivinar si un paso ha pasado.

Prioridad y riesgo

No todos los casos de prueba son igual de importantes. Marca cada uno como Must, Should o Could: Must es lo que tiene que funcionar desde el primer día, como crear un presupuesto o enrutar un caso. Añade el riesgo: lo que cuesta si falla después de la puesta en producción. Los testers empiezan por Must y riesgo alto, así que las pruebas importantes se hacen aunque se acabe el tiempo.

Añade también los caminos negativos: un campo obligatorio vacío, un descuento por encima del límite, un usuario de otra unidad de negocio que no debería ver un registro.

En UAT StudioImporta tus casos de prueba desde Excel con las columnas Priority y Risk, léelos desde Azure DevOps Test Plans, o parte de los guiones de Dynamics 365 de la biblioteca de plantillas, un complemento de todos los planes de pago. Con el diseño de pruebas con IA, la IA propone casos de prueba a partir de tus historias de usuario en Azure DevOps, también con el propio modelo de tu empresa, como Microsoft Foundry / Azure OpenAI. Nada se convierte en caso de prueba hasta que lo apruebas.

Testers

Elige a personas que hacen el trabajo cada día: gestores de cuentas, agentes de servicio y sus responsables para aprobaciones, colas y paneles. Toma testers de cada equipo y país que usa Dynamics 365, porque sus procesos, unidades de negocio y listas de precios son distintos.

Cuánto tiempo

Acuerda el tiempo por tester con su responsable y reserva tiempo para volver a probar. Los testers que siguen atendiendo llamadas o visitando clientes no terminarán.

Un arranque

Empieza con un arranque breve: por qué importa su prueba, cómo abrir el entorno de UAT, cómo registrar un resultado y cómo registrar una incidencia. Haz que cada tester inicie sesión una vez durante el arranque y abra la aplicación. La mayoría de los problemas con licencias, roles y el entorno equivocado salen ahí, no el día de prueba.

Un día de prueba o una semana

Un día de prueba da concentración y respuestas rápidas, y encaja con un alcance pequeño. Una semana en bloques de unas horas deja margen para nuevas builds y nuevas pruebas, y encaja con una puesta en producción con muchos procesos. En ambos casos, fija una hora para el triaje cada día.

Durante la UAT

Registrar incidencias

Una buena incidencia se puede corregir sin reunión. Pide a los testers:

• El paso, lo que esperaban y lo que pasó en su lugar.
• Una captura de pantalla de la página, con el mensaje de error si lo hubo.
• El enlace al registro. Está en la barra de direcciones del navegador y lleva al consultor directamente a la oportunidad o al caso donde falló.
• El usuario y el rol de seguridad con los que probaron.

En UAT StudioLa extensión del navegador para Chrome y Edge muestra las pruebas en un panel lateral junto a Dynamics 365. Un paso fallido incluye la captura de pantalla, el enlace al registro y los mensajes de error de la página. El rol del tester aparece junto a su nombre en la incidencia.

Triaje

Revisa las nuevas incidencias cada día, con el negocio y el equipo de Dynamics 365 juntos. Dale a cada una una gravedad y alguien que la corrija, y decide:

• Corregir: un problema real, se corrige en esta versión.
• Rechazar: Dynamics 365 funciona según lo diseñado, o la prueba estaba mal.
• Solicitud de cambio: un deseo, no un defecto. Va al backlog, no a esta versión.

Envía las incidencias que hay que corregir a los desarrolladores, a menudo en Azure DevOps, con la captura de pantalla y el enlace al registro.

Volver a probar

Cuando la corrección está en una nueva build en el entorno de UAT, el tester que encontró la incidencia vuelve a probar el paso. Anota en qué build se hizo cada nueva prueba. Después de una corrección grande, vuelve a probar también los procesos de alrededor.

Estado diario

Envía cada día al comité de dirección un estado breve: avance frente al plan, incidencias abiertas por gravedad y qué bloquea. Sin sorpresas en la reunión de go/no-go.

En UAT StudioEl triaje se hace en una pantalla compartida con Fix, Reject y Change request. Una incidencia se convierte en un elemento de trabajo Bug en Azure DevOps; cuando se completa allí, la incidencia pasa a Ready for retest y el tester recibe un correo. Cada ronda guarda su versión, su build y su entorno. Microsoft Teams recibe en un canal las nuevas incidencias, rondas y sign-offs.

Sign-off y go/no-go

La UAT termina con una decisión del negocio. Acuerda los criterios de salida antes del primer día de prueba, para que nadie discuta sobre ellos al final:

• No hay ninguna incidencia Critical abierta.
• Todos los casos de prueba Must han pasado.
• 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.

Quién firma

El responsable de cada proceso da el sign-off, como el director de ventas para el proceso del lead al presupuesto y el responsable de atención al cliente para la gestión de casos. Eligen: aceptado, aceptado con condiciones o rechazado. Anota cada condición, con quién la cumple y para cuándo. Después, el comité de dirección decide sobre la puesta en producción.

Qué incluye el informe

• Qué estaba en el alcance y qué no se probó.
• Los resultados por proceso o equipo, y por prioridad.
• El entorno, las soluciones y la build que se probaron.
• Las incidencias abiertas por gravedad, con la decisión sobre cada una.
• Los sign-offs, con sus condiciones, y los riesgos conocidos de las primeras semanas.

En UAT StudioSign-off por grupo: Accepted, Accepted with conditions o Rejected. Por defecto, nadie puede aceptar mientras haya una incidencia Critical abierta. El informe de go/no-go está listo en PDF o como diapositivas en cuanto llega el último resultado.

Rondas de regresión con un ritmo fijo

Después de la puesta en producción, las actualizaciones siguen llegando durante todo el año, y cada una puede cambiar un formulario, un flujo o un permiso. Tus casos de prueba de la UAT son la mejor prueba de regresión que tienes: describen exactamente lo que el negocio aceptó.

• Elige un ritmo, por ejemplo una ronda de regresión cada mes o cada trimestre, y pon ya las fechas en el calendario de los testers.
• Antes de cada ronda, lee la hoja de ruta de Microsoft y los mensajes para tus administradores, y anota qué cambios afectan a tus procesos.
• Prueba primero en un entorno sandbox las funciones en versión preliminar o en acceso anticipado, antes de que lleguen a tus usuarios.
• Vuelve a probar los casos de prueba Must, y los Should si hay tiempo, con algunos testers del negocio.
• Registra las incidencias como en la UAT y corrígelas antes de que el cambio llegue a tus usuarios.

En UAT StudioElige Dynamics 365 como CRM del proyecto. Start a regression round copia los casos de prueba que elijas de una UAT anterior, con sus pasos, datos de prueba y resultados esperados: Must and Should, Only Must o All test cases in scope.

De uso libre

Para todo lo que hay que organizar antes, durante y después de la UAT, consulta la checklist de UAT para la puesta en producción de un CRM, también como Excel gratuito. Para lo que hace UAT Studio en una UAT de Dynamics 365, consulta Dynamics 365 UAT.

Microsoft, Dynamics 365, Power Platform, Azure DevOps y Microsoft Teams son marcas comerciales del grupo de empresas Microsoft. UAT Studio no está afiliado a Microsoft ni cuenta con su respaldo.