Por qué los testers de negocio necesitan otros casos de prueba
Una prueba de sistema la hacen personas que construyeron el sistema o lo conocen bien. Una prueba de aceptación de usuario la hacen personas que lo usan: conocen el trabajo, no la configuración. No saben qué campo es nuevo, qué flujo se ejecuta en segundo plano ni qué quiso decir el desarrollador.
Por eso, un caso de prueba de UAT tiene que funcionar para alguien que:
- se sabe el proceso de negocio de memoria, pero no las pantallas nuevas;
- tiene unas horas entre otras tareas, no una semana;
- nunca debería tener que adivinar si un paso ha pasado o ha fallado;
- se parará a esperar cuando un paso no esté claro, y perderá tiempo.
Cada hora dedicada a casos de prueba claros ahorra muchas horas en los días de prueba: menos preguntas, menos incidencias que resultan ser malentendidos y resultados en los que puedes confiar en el go/no-go.
A partir de historias de usuario y procesos
Los casos de prueba salen de dos sitios, y necesitas ambos.
Historias de usuario y sus criterios de aceptación
Una historia de usuario dice qué quiere hacer alguien y por qué: Como comercial quiero convertir un lead cualificado, para obtener una cuenta, un contacto y una oportunidad. Sus criterios de aceptación dicen cuándo está terminada. Cada criterio de aceptación es candidato a un paso o a un caso de prueba.
Comprueba la cobertura: cada historia de usuario dentro del alcance necesita al menos un caso de prueba. Una historia sin caso de prueba es un hueco, y los huecos se descubren en producción.
Procesos de negocio, de extremo a extremo
Las historias de usuario se cortan en trozos pequeños para los desarrolladores. El negocio trabaja en procesos que atraviesan muchas historias: lead to cash, quote to order, la gestión de casos desde el correo hasta la resolución. Una historia puede pasar por sí sola mientras el proceso se rompe en el traspaso entre dos equipos.
Por eso, añade casos de prueba de extremo a extremo que sigan un proceso de principio a fin, a través de los roles: el comercial hace la oferta, el responsable la aprueba, el pedido pasa a finanzas. A menudo son los casos de prueba que más importan al negocio.
En UAT StudioLee las historias de usuario desde Jira o Azure DevOps en la tarjeta User stories, y marca Only stories without test cases para ver los huecos. Con el módulo AI test design, la IA propone casos de prueba a partir de tus historias o de la descripción de un proceso, también con el modelo propio de tu empresa. Nada se convierte en caso de prueba hasta que lo apruebas. Sin el módulo, Prepare with your own AI te da un prompt para pegar en la IA de tu empresa; los pasos marcados con [CHECK] son suposiciones que hay que comprobar.
Un objetivo por caso de prueba
Un caso de prueba prueba un escenario de negocio, con un objetivo. Su título dice lo que consigue el tester, con las palabras del negocio:
- Convertir un lead con una cuenta existente
- Aprobar una oferta con un descuento de más del 20%
- Enrutar un correo de un cliente conocido a la cola correcta
No Probar el objeto lead, ni Leads, oportunidades y ofertas. Cuando un caso de prueba tiene varios objetivos, un fallo los bloquea todos, y el resultado dice poco: ¿qué falló y qué sigue funcionando?
¿Qué tamaño tiene un caso de prueba?
Por regla general, un caso de prueba tiene entre tres y quince pasos, y a un tester le lleva de cinco a veinte minutos. Si es mucho más largo, probablemente tiene más de un objetivo: divídelo. Si es mucho más corto, quizá deba ir junto a otro cercano.
Los casos de prueba de extremo a extremo son la excepción. Siguen un proceso entero y pueden ser más largos. Mantenlos, pero asegúrate de que cada parte del proceso también tenga su propio caso de prueba más corto, para que un fallo sea fácil de localizar.
Pasos con un resultado esperado
Cada paso tiene dos partes: una acción (lo que hace el tester) y un resultado esperado (lo que debería ocurrir). El resultado esperado es lo que hace que un paso se pueda probar. Sin él, el tester decide qué es suficiente, y dos testers deciden de forma distinta.
Escribe la acción
- Una acción por paso. Abre el lead y haz clic en Convert está bien; cinco clics en un paso, no.
- Empieza con un verbo: abre, haz clic, rellena, elige, guarda.
- Usa las etiquetas tal como aparecen en pantalla, en negrita o entre comillas.
- Di qué hacer, no cómo funciona el sistema por dentro. Guarda la oferta, no lanza el flujo de aprobación.
Escribe el resultado esperado
- Di lo que ve el tester: un mensaje, un valor en un campo, un registro nuevo, un estado.
- Sé concreto. La oportunidad está en la fase Qualification, no funciona.
- Nombra lo que no debería ocurrir cuando importa: No se crea una segunda cuenta.
- Para lo que el sistema hace por sí solo, di dónde mirar: El caso aparece en la cola Benelux Support en menos de un minuto.
Datos de prueba y roles
Datos de prueba
Los testers pierden más tiempo buscando datos que en cualquier otra parte de una UAT. Pon los datos en el caso de prueba siempre que importen: qué cliente, qué producto, qué lista de precios o price book, qué importe. Prepara esos datos en el entorno de pruebas antes del primer día de pruebas.
- Usa nombres que se vean claramente como datos de prueba, como Jansen Logistics (test).
- Da a cada tester sus propios registros cuando cambien datos, para que dos personas no editen la misma oportunidad.
- Añade valores en los límites: un descuento justo por debajo y justo por encima del límite, un campo obligatorio vacío.
- No uses datos personales reales de clientes cuando puedas evitarlo.
Roles
En un CRM, lo que un usuario puede ver y hacer depende de su rol: un perfil y conjuntos de permisos en Salesforce, roles de seguridad y una unidad de negocio en Dynamics 365. Una UAT demuestra que cada rol puede hacer su trabajo, y solo su trabajo. Por eso cada caso de prueba dice qué rol lo prueba, y el tester inicia sesión con un usuario de prueba que tiene exactamente ese rol.
Nunca pruebes con un administrador. Un administrador ve y puede hacer de todo, así que los problemas que una UAT debería encontrar quedan ocultos.
En UAT StudioCada paso tiene una acción, un resultado esperado y, opcionalmente, datos de prueba. Cada tester tiene un Test role y una Test account, que aparecen en la parte superior de sus pruebas como Log in as …, y el rol aparece junto a su nombre en cada incidencia que registra.
Prioridad y riesgo
Nunca hay tiempo suficiente para probarlo todo igual de bien. Marca cada caso de prueba para que los importantes se prueben primero, y se terminen aunque se acabe el tiempo.
| Prioridad | Qué significa | Ejemplo |
|---|---|---|
| Must | Tiene que funcionar el primer día. Si falla, la puesta en producción está en riesgo. | Crear y enviar una oferta; enrutar un caso a la cola correcta. |
| Should | Importante, pero el negocio puede vivir un tiempo con una solución provisional. | Un dashboard para el director de ventas. |
| Could | Deseable. Se prueba si hay tiempo. | Una vista de lista ordenada por región. |
Añade el riesgo al lado: lo que cuesta si esto falla después de la puesta en producción. Un precio erróneo en una factura es riesgo alto; una etiqueta errónea en un informe es riesgo bajo. Dentro de la misma prioridad, los testers empiezan por el riesgo alto.
Sé estricto con Must. Cuando la mitad de los casos de prueba son Must, la etiqueta no significa nada: resérvala para aquello sin lo que el negocio no puede funcionar. Acuerda las prioridades con los responsables de los procesos: ellos también deciden en el go/no-go, donde los casos de prueba Must que no han pasado son los que más cuentan.
En UAT StudioFija Priority (Must, Should, Could) y Risk (High, Medium, Low) en el editor o en una columna al importar. También se leen los valores de otras herramientas: Critical y High pasan a ser Must, Medium y Normal Should, Low Could. Los testers ven primero sus casos de prueba Must, y dentro de cada prioridad, primero los de riesgo alto.
Un ejemplo
Caso de prueba 12: Aprobar una oferta con un descuento de más del 20%
Prioridad Must, riesgo High. Historia de usuario CRM-118. Rol: comercial (pasos 1 a 3) y director de ventas (pasos 4 y 5).
| Paso | Action | Resultado esperado | Datos de prueba |
|---|---|---|---|
| 1 | Abre la oportunidad y crea una oferta nueva. | Se abre una oferta, vinculada a la oportunidad, con sus productos. | Oportunidad Jansen Logistics – Support |
| 2 | Pon el descuento en el 25% y guarda. | La oferta se guarda. Muestra el estado Needs approval. | Descuento del 25% |
| 3 | Intenta enviar la oferta al cliente. | No se puede enviar. Un mensaje indica que la oferta necesita aprobación. | |
| 4 | Inicia sesión como director de ventas y abre la solicitud de aprobación. | La solicitud muestra la oferta, el descuento y el comercial. | Usuario de prueba Sales manager Benelux |
| 5 | Aprueba la solicitud. | La oferta muestra Approved, y el comercial recibe un correo. |
Fíjate en lo que hace que funcione: un objetivo en el título, una acción por paso, un resultado esperado que el tester puede comprobar, los datos y el rol indicados, y un camino alternativo en el paso 3. Añade un segundo caso de prueba para un descuento por debajo del límite, que no debería necesitar aprobación.
Errores comunes
- Sin resultado esperado, o funciona como se espera. El tester tiene que adivinar qué se esperaba.
- Lenguaje técnico. Nombres de campos de la base de datos, nombres de objetos o comprueba que se dispara el trigger. Usa las palabras de la pantalla.
- Demasiados objetivos en un caso de prueba. Un fallo bloquea el resto, y el resultado te dice poco.
- Solo el camino feliz. Añade un campo obligatorio vacío, un valor por encima de un límite, un usuario que no debería ver un registro.
- Faltan datos de prueba. Abre una oportunidad: ¿cuál? ¿En qué fase, con qué productos?
- Sin rol. El tester usa la cuenta que tenga, a menudo una con demasiados permisos.
- Copiado de la prueba de sistema. Escrito para desarrolladores, con pasos que los testers de negocio no pueden seguir.
- Todo es Must. Entonces nada lo es, y las pruebas importantes no se hacen primero.
- Escrito una vez, nunca leído. Los guiones que nadie revisó antes de los días de prueba están llenos de etiquetas antiguas y menús equivocados.
Pide a un usuario clave que los revise
Antes de los días de prueba, pide a un usuario clave del negocio que lea los casos de prueba y pruebe dos o tres en el entorno de pruebas. Encuentra lo que quien los escribió no ve: un paso que da por sabido algo, una etiqueta que cambió, un proceso que funciona distinto en otro país.
Comprueba a la vez que cada historia de usuario dentro del alcance tiene un caso de prueba, que cada rol dentro del alcance prueba algo y que los datos de prueba existen. Y conserva los casos de prueba después de la puesta en producción: son tu prueba de regresión para la próxima versión del CRM.
En UAT StudioImporta casos de prueba desde Excel, Azure DevOps, Jira con Xray o Zephyr Scale, o TestRail, o escríbelos en el editor. La biblioteca de plantillas, un complemento de todos los planes de pago, tiene guiones listos para Salesforce y Dynamics 365 que adaptas a tu propia configuración.
De uso libre
Para todo lo demás 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 archivo Excel gratuito.