Por qué un CRM necesita pruebas de regresión
Después de la puesta en producción, tu CRM sigue cambiando, aunque tu propio equipo no cambie nada. Salesforce y Microsoft actualizan la plataforma para todos los clientes. La mayoría de los cambios son mejoras. Algunos cambian una página, un ajuste predeterminado o la forma en que funciona una función, y de vez en cuando uno rompe algo de lo que depende tu negocio.
Una prueba de regresión responde a una pregunta: ¿sigue funcionando lo que el negocio aceptó en la puesta en producción? No es una nueva UAT. Es una comprobación breve y centrada de los procesos que más importan, hecha antes de que el cambio llegue a tus usuarios, por personas que conocen el trabajo.
Tus propias versiones necesitan la misma comprobación. Una nueva integración, un campo nuevo en la oferta, un cambio en el enrutamiento de casos: cada uno puede afectar a algo que antes funcionaba.
Salesforce: tres versiones al año
Salesforce tiene tres versiones principales al año: Spring, Summer y Winter. La versión Winter llega en otoño y lleva el número del año siguiente. Todas las orgs se actualizan, en fechas que Salesforce publica con antelación.
- La sandbox preview. Los sandboxes en una instancia de preview reciben la nueva versión algunas semanas antes que producción. Esa es tu ventana para probar. Antes de cada versión, Salesforce indica qué instancias están en la preview y qué hacer para mantener un sandbox en ella. Un refresh puede meter o sacar un sandbox de la preview, así que compruébalo a tiempo.
- Las notas de la versión. Léelas para las clouds y funciones que usas. Busca lo que se activa automáticamente para ti y lo que cambia el aspecto de las páginas con las que trabajan tus usuarios.
- Release updates. Algunos cambios se anuncian en Setup con una fecha a partir de la cual se aplican. Pruébalos en el sandbox antes de esa fecha, para que no te sorprendan en producción.
Así que en Salesforce el ritmo viene dado: una ronda de regresión en la ventana de preview de cada versión, tres veces al año.
En UAT StudioElige Salesforce como CRM del proyecto. Desde unos dos meses antes de una versión, la página de proyectos muestra Coming CRM releases, con la fecha de la sandbox preview, la fecha de producción y un enlace a las notas de la versión. Salesforce todavía puede mover estas fechas, así que consulta las notas de la versión.
Dynamics 365: actualizaciones todo el año
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.
Eso significa que ya no hay un gran momento al año en torno al cual planificar tus pruebas. Los cambios llegan en pasos más pequeños, más a menudo. Esperar a una gran versión ya no funciona, y probar después de cada cambio es demasiado.
Elige un ritmo fijo
La respuesta es una ronda de regresión con un ritmo fijo, publique lo que publique Microsoft entretanto:
- Cada mes cuando el CRM es central para el negocio, usas muchas apps y funciones, o activas funciones nuevas a menudo.
- Cada trimestre para una configuración estable con pocos cambios propios.
- Una ronda extra antes de que un cambio propio pase a producción, o cuando un cambio de Microsoft afecta claramente a uno de tus procesos clave.
Pon las fechas en el calendario de los testers para todo el año. Un ritmo fijo es más fácil de mantener que una ronda que se planifica cada vez que surge algo.
Antes de cada ronda
- Lee la hoja de ruta de Microsoft y los mensajes para tus administradores en el Microsoft 365 admin center, y anota qué cambios afectan a tus procesos.
- Prueba primero las funciones en preview en un entorno sandbox, antes de que lleguen a tus usuarios.
- Asegúrate de que el sandbox en el que pruebas tiene la misma versión y las mismas soluciones que producción.
En UAT StudioElige Dynamics 365 como CRM del proyecto, y empieza cada ronda con Start a regression round, desde el proyecto de tu puesta en producción o de tu última ronda.
En UAT StudioEn Setup, elige Check the Dynamics 365 updates: Every quarter o Every month. La página de proyectos muestra entonces el periodo actual con un enlace a la hoja de ruta, y los administradores reciben un email por periodo, dos semanas antes de que empiece.
Elegir qué volver a probar
Una ronda de regresión no es el lugar para probarlo todo otra vez. Elige, en este orden:
- Los casos de prueba Must. Lo que tiene que funcionar cada día: crear una oferta, convertir un lead, enrutar un caso, las aprobaciones. Pruébalos en cada ronda.
- Lo que afecta el cambio. Lee las notas de la versión o la hoja de ruta con la lista de tus procesos al lado. Un cambio en las ofertas significa los casos de prueba de ofertas, también los Should y Could.
- Integraciones y automatización. Los enlaces con el ERP, el sitio web o el correo, y los flujos que se ejecutan en segundo plano. Se rompen sin hacer ruido, así que pruébalos a propósito.
- Los casos de prueba Should, cuando haya tiempo.
Después mira lo que ha cambiado tu propio equipo desde la última ronda. Todo lo que habéis construido vosotros y nadie ha probado junto con el cambio de la plataforma también entra en la ronda.
Ten una lista corta de lo que es crítico
Anota, una vez, los diez a veinte procesos sin los que el negocio no puede pasar ni un día. Son el núcleo de cada ronda de regresión. Revisa la lista cada medio año con los responsables de los procesos, y después de cada gran cambio propio.
En UAT StudioCon el complemento Release readiness, Review the release muestra qué casos de prueba toca una versión de Salesforce o una actualización de Dynamics 365, con el motivo, propone casos de prueba para lo que aún no está cubierto y enumera las actualizaciones obligatorias con sus fechas. La ronda de regresión recibe entonces exactamente los casos de prueba Must, los tocados que mantienes y los nuevos que apruebas. Un fallo en la ronda indica con qué cambio llegó. €99 al mes: añádelo en Plan & billing.
Reutiliza tus casos de prueba
La mejor prueba de regresión que tienes es el conjunto de casos de prueba de la UAT de tu puesta en producción. Describen exactamente lo que el negocio aceptó, con los pasos, los datos de prueba y los resultados esperados. No escribas casos nuevos para cada ronda.
- Conserva los casos de prueba después de la puesta en producción, en un solo lugar, con su prioridad.
- Actualízalos cuando cambie tu propio proceso, para que la próxima ronda pruebe el CRM tal como es ahora, no como era en la puesta en producción.
- Comprueba los datos de prueba antes de cada ronda. Un refresh del sandbox o una copia de producción puede eliminar o cambiar los registros que usan los casos de prueba.
- Añade un caso de prueba por cada incidencia grave encontrada en producción, para detectarla la próxima vez.
Aquí merece la pena tener casos de prueba que los testers de negocio puedan seguir: se reutilizan una y otra vez. Consulta Casos de prueba que entienden los testers de negocio.
En UAT StudioStart a regression round copia los casos de prueba del proyecto del que partes, con sus pasos, datos de prueba y resultados esperados. Elige cuáles se incluyen: Must and Should, Only Must o All test cases in scope; un caso de prueba sin prioridad cuenta como Should. El nuevo proyecto recibe los grupos y la configuración, y tú invitas a los testers en Setup. No se inventa ni se cambia nada.
Quién prueba y cuánto tiempo
Quién
Una ronda de regresión necesita menos personas que una UAT, pero deberían seguir viniendo del negocio. Pide uno o dos usuarios clave por proceso: personas que hacen el trabajo cada día y notan enseguida cuando algo no va bien. El administrador del CRM prepara la ronda y prueba lo que se ejecuta en segundo plano, pero no debería ser el único tester.
Que prueben las mismas personas ronda tras ronda. Se vuelven más rápidas y notan pequeños cambios que un tester nuevo pasaría por alto.
Duración
- Preparación: uno o dos días para leer los cambios, elegir los casos de prueba y comprobar los datos de prueba.
- Pruebas: unas horas por tester, repartidas en uno o dos días para una ronda mensual, hasta una semana para una versión de Salesforce con muchos cambios.
- Correcciones y repruebas: reserva unos días antes de que el cambio llegue a producción, para las incidencias que encuentres.
En Salesforce, eso tiene que caber en la ventana de preview. Empieza al principio de la ventana, no en la última semana.
Registrar lo que encuentras
Registra las incidencias como en la UAT: el paso, lo que esperabas, lo que ocurrió en su lugar, una captura de pantalla y el enlace al registro. Haz el triaje cada día con el equipo de CRM. Para una incidencia causada por la plataforma, mira primero en las notas de la versión o en la hoja de ruta: a menudo es un cambio conocido con un ajuste que modificar.
En UAT StudioCada ronda guarda su versión, su build y su entorno, para que el informe de go/no-go diga qué se probó. Después de las correcciones, Start round 2 en el dashboard con Failed and blocked only vuelve a probar solo lo que salió mal; los resultados de la ronda anterior se conservan.
Sign-off antes de producción
Una ronda de regresión termina como una UAT, con una decisión, solo que más breve. Acuerda los criterios de salida una vez y úsalos en cada ronda:
- Todos los casos de prueba Must han pasado.
- No hay ninguna incidencia Critical abierta.
- Cada incidencia High abierta tiene una solución provisional que el negocio acepta, o una corrección antes de que el cambio llegue a producción.
El responsable de cada proceso da el sign-off de su parte: aceptado, aceptado con condiciones o rechazado. En una versión de Salesforce no puedes detener la actualización, así que un rechazo significa una corrección o una solución provisional antes de la fecha de producción, y un mensaje a los usuarios. En un cambio propio, un rechazo significa que espera.
Guarda el resultado de cada ronda. Al cabo de un año tienes un registro claro de qué se probó después de cada cambio y quién lo aceptó. Para saber cómo preparar la decisión, consulta La decisión go/no-go.
En UAT StudioUna ronda de regresión es un proyecto propio, con la versión como su Release, para que su informe de go/no-go diga de qué versión del CRM se trata. Los responsables de los procesos dan el sign-off por grupo, y el sign-off pertenece a esa ronda.
De uso libre
La checklist de UAT para la puesta en producción de un CRM también sirve para una ronda de regresión, como archivo Excel gratuito. Para cada plataforma, consulta Salesforce UAT y Dynamics 365 UAT.
Salesforce es una marca comercial de Salesforce, Inc. Microsoft y Dynamics 365 son marcas comerciales del grupo de empresas Microsoft. UAT Studio no está afiliado a Salesforce ni a Microsoft ni cuenta con su respaldo.