Salesforce UAT: guía práctica

Cuándo necesitas una UAT en Salesforce

Una prueba de aceptación de usuario responde a una pregunta: ¿puede el negocio hacer su trabajo con esta versión de Salesforce? 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 Sales Cloud o Service Cloud, o una migración desde otro CRM.
• Un nuevo cloud o un gran cambio. Añadir Service Cloud junto a Sales Cloud, CPQ, una nueva integración con el ERP o una nueva forma de enrutar los casos.
• Cada versión de Salesforce. Salesforce publica tres versiones al año: Spring, Summer y Winter. La versión Winter llega en otoño y lleva el número del año siguiente. Cada versión puede cambiar cómo funciona tu org, aunque tú no hayas cambiado nada.
• La sandbox preview. Los sandboxes en una instancia de preview reciben la nueva versión unas semanas antes que producción. Esa es tu ventana para probar. Antes de cada versión, Salesforce publica qué instancias están en la preview y qué hacer para mantener un sandbox en ella. Compruébalo a tiempo, porque un refresh puede meter o sacar un sandbox de la preview.

Una puesta en producción necesita una UAT completa. Una versión necesita una prueba de regresión más corta de los procesos que más importan. Más sobre esto en Después de la puesta en producción.

El sandbox

Nunca pruebes en producción. Salesforce tiene cuatro tipos de sandbox. Dos de ellos sirven para una UAT.

Planifica el refresh

Un refresh sustituye todo lo que hay en el sandbox por una nueva copia de producción. Cada tipo de sandbox tiene un tiempo mínimo entre refreshes, y el sandbox Full tiene el más largo. Así que planifícalo:

• Haz el refresh antes de la UAT, nunca durante. Comprueba cuándo se puede volver a hacer refresh del sandbox.
• Despliega la versión en el sandbox después del refresh. El trabajo que solo existía en el sandbox desaparece.
• Haz los pasos posteriores al refresh: apunta las integraciones y las named credentials a sistemas de prueba, no a producción, y desactiva los trabajos programados que no deban ejecutarse.
• Comprueba la entrega de correo electrónico. Un sandbox nuevo o con refresh solo envía correos del sistema. Las respuestas de web-to-lead, las aprobaciones y los correos de casos necesitan más, pero un sandbox Full contiene las direcciones de correo reales de tus contactos. Usa direcciones de prueba antes de abrirlo.

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, la región y el tipo de registro correctos.
• Productos y listas de precios. Un producto necesita un precio en la lista de precios estándar antes de poder estar en otra lista de precios. Comprueba que las listas de precios de cada equipo de ventas están activas.
• Registros abiertos con los que trabajar: oportunidades en distintas fases, casos abiertos y casos cerca de un hito si pruebas los derechos (entitlements).
• Nada de datos personales reales siempre que puedas evitarlo. Un sandbox Full lo copia todo, así que enmascara o anonimiza lo que los testers no necesitan ver.

Usuarios por perfil y conjunto de permisos

Una UAT demuestra que cada rol puede hacer su trabajo, y solo su trabajo. Crea un usuario de prueba para cada combinación de perfil, rol y conjuntos de permisos que pruebes, como un comercial, un director de ventas y un agente de servicio. Cada tester tiene su propio usuario, para que nunca trabajen dos personas con el mismo usuario a la vez.

Después de un refresh, Salesforce añade el nombre del sandbox a cada nombre de usuario y .invalid a la dirección de correo de cada usuario. Pon como correo de cada usuario de prueba una dirección que el tester lea, o los restablecimientos de contraseña y los correos de aprobación no llegarán a nadie.

Iniciar sesión como permite a un administrador ver Salesforce con los ojos de otro usuario. Es una buena forma de revisar un problema que comunica un tester. Para la prueba en sí, los testers usan su propio usuario de prueba: así sabes que el perfil y los conjuntos de permisos son correctos.

Qué contar a los testers sobre el sandbox

• La dirección del sandbox. Lleva el nombre del sandbox, o inician sesión a través de test.salesforce.com. La página de inicio de sesión normal de Salesforce abre producción.
• Su nombre de usuario, que termina con el nombre del sandbox, y cómo obtienen su contraseña.
• 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, antes de que pierdan una mañana.

En UAT StudioCada tester tiene un Test role 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 sandbox, los buzones de prueba y a quién llamar.

Casos de prueba a partir de historias de usuario y procesos

Parte de los procesos del negocio, no de los objetos de Salesforce. Dos procesos cubren la mayor parte de una UAT de Salesforce:

• Lead to cash. Un candidato entra por web-to-lead, se asigna y se convierte. La oportunidad recibe productos de la lista de precios, se crea y se aprueba un presupuesto, se gana el acuerdo y el pedido o el contrato pasa al siguiente equipo o sistema.
• Gestión de casos. Un caso entra por email-to-case o por el portal, se enruta a la cola o al agente adecuados, sigue sus derechos e hitos, se resuelve con un artículo de Knowledge, se escala cuando hace falta y se cierra.

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

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 que no debería ver un registro.

En UAT StudioImporta tus casos de prueba desde Excel con las columnas Priority y Risk, o parte de los guiones de Salesforce de la biblioteca de plantillas, un complemento de todos los planes de pago. Los testers ven primero sus casos de prueba Must.

Testers

Elige a personas que hacen el trabajo cada día: comerciales, agentes de servicio y sus responsables para aprobaciones, previsiones e informes. Toma testers de cada equipo y país que usa Salesforce, porque sus procesos y listas de precios son distintos.

Cuánto tiempo

Pide el tiempo por tester, no por equipo, y acuérdalo con su responsable. Planifica los guiones para que cada tester sepa cuánto tiene que hacer. Reserva tiempo para volver a probar después de las correcciones. 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 iniciar sesión en el sandbox, cómo registrar un resultado y cómo registrar una incidencia. Haz que cada tester inicie sesión una vez durante el arranque. La mayoría de los problemas con usuarios y contraseñas salen ahí, no el día de prueba.

Un día de prueba o una semana

• Un día de prueba, en una sala o en una llamada, da concentración y respuestas rápidas. Encaja con un alcance pequeño y con testers a los que cuesta liberar más tiempo.
• Repartido en una semana, en bloques de unas horas, deja margen para correcciones y nuevas pruebas entre bloques. 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.
• El enlace al registro. Está en la barra de direcciones del navegador y lleva al desarrollador directamente a la oportunidad o al caso donde falló.
• El usuario con el que probaron, para que el equipo sepa qué perfil y qué conjuntos de permisos se usaron.

En UAT StudioLa extensión del navegador para Chrome y Edge muestra las pruebas en un panel lateral junto a Salesforce. Un paso fallido incluye la captura de pantalla, el enlace al registro y los mensajes de error de la página. Una incidencia muestra el registro como enlace, con el sandbox incluido.

Triaje

Revisa las nuevas incidencias cada día, con el negocio y el equipo de Salesforce 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: Salesforce 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.

Volver a probar

Cuando se despliega una corrección en el sandbox, 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. Cíñete a los hechos. 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. Ready for retest envía un correo a quien vuelve a probar. Un resumen diario por correo, o en Microsoft Teams, muestra los resultados y las incidencias del día anterior.

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 lead to cash 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 sandbox, la versión 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.

Una ronda de regresión por cada versión de Salesforce

Después de la puesta en producción, las versiones siguen llegando: tres al año. Cada una puede cambiar una página, un flujo o un permiso. Tus casos de prueba de la UAT son la mejor prueba de regresión que tienes, porque describen exactamente lo que el negocio aceptó.

• Conserva los casos de prueba después de la puesta en producción, con sus pasos, datos de prueba y resultados esperados.
• Lee las notas de la próxima versión y comprueba qué funciones se activan automáticamente para ti.
• Comprueba que tu sandbox de UAT está en la sandbox preview y planifica la ronda en la ventana de la preview.
• 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 la versión llegue a producción.

En UAT StudioElige Salesforce como CRM del proyecto. La página de proyectos muestra entonces las próximas versiones de Salesforce, con la fecha de la sandbox preview, la fecha de producción y las notas de la versión. Start a regression round copia los casos de prueba que elijas: 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 Salesforce, consulta Salesforce UAT.

Salesforce, Sales Cloud y Service Cloud son marcas comerciales de Salesforce, Inc. UAT Studio no está afiliado a Salesforce ni cuenta con su respaldo.