Pruebas de aceptación con el negocio
En resumen: Las pruebas de aceptación preguntan otra cosa: no «¿el sistema hace lo escrito?», sino «¿puedo hacer mi trabajo con él?». Las hacen personas del negocio, con tareas reales y datos verosímiles, mientras QA prepara, observa y registra. Los hallazgos son defectos, solicitudes de cambio o preguntas. Cuanto más tarde se oye «no es esto», más caro resulta; por eso la demo y el prototipo muestran la dirección antes.
Problema
Funciona, pero no es lo que necesitamos
Los códigos promocionales pasaron todos los tests: 10 %, no valen para productos rebajados, un pedido pagado, un plazo de vigencia. Los escenarios están en verde, y los tests de CI también.
En las pruebas de aceptación, la contadora hace lo que hace todos los meses: concilia los descuentos. Abre un pedido y ve «Descuento: 2,00 €». ¿Con qué código? No lo dice. No tiene forma de comparar los descuentos con las campañas. «Todo funciona, pero yo no puedo hacer mi trabajo.» Faltan tres días para el lanzamiento.
La idea
Las pruebas de aceptación de usuario
Todos los tests hasta ahora preguntaban «¿el sistema hace lo escrito?». Eso es verificación. Las pruebas de aceptación de usuario (user acceptance testing, UAT) preguntan otra cosa: ¿puedo hacer mi trabajo con este sistema? Eso es validación.
Por eso las hacen las personas que van a trabajar con el sistema: la contadora, el empleado de marketing, el almacén. No QA ni los programadores. Ellas hacen su trabajo real, con tareas de su día a día y con datos verosímiles, en un entorno que se parece al real.
QA no sobra. QA prepara el entorno y los datos, ayuda a sacar las tareas de los procesos de trabajo, observa y registra los hallazgos. Pero el veredicto «esto me basta» no lo puede dar nadie más que el negocio.
La idea
Cómo transcurre una aceptación
Preparación. Qué personas, qué procesos de trabajo, qué entorno, qué datos. Y los criterios de entrada: las pruebas del sistema pasaron, no hay defectos críticos abiertos. Las personas del negocio tienen poco tiempo, y no deben gastarlo en errores que los niveles más bajos debieron detectar.
Realización. Cada una hace sus tareas: «lanza una campaña de otoño», «concilien los descuentos de octubre». QA mira sin dar pistas y anota dónde se detiene la persona, qué busca, qué la sorprende.
Hallazgos. Son de tres tipos, y cada uno sigue su camino:
- un defecto: el sistema no hace lo acordado. Se reporta y se corrige;
- una solicitud de cambio: el sistema hace lo acordado, pero lo acordado no basta. Pasa por la gestión de cambios: evaluación, prioridad, decisión;
- una pregunta: algo que nadie ha decidido. Se anota, y hay alguien que responde.
Decisión. Aceptado, aceptado con condiciones o no aceptado. Decide el dueño, según los criterios de salida acordados antes del inicio.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 describe las pruebas de aceptación como uno de los niveles de prueba y da sus formas principales: de usuario, operativas, contractuales y regulatorias, y las pruebas alfa y beta (el módulo «Niveles, tipos y proceso»). ISTQB tiene además una certificación aparte sobre pruebas de aceptación, Certified Tester Acceptance Testing (CT-AcT). Trata de la colaboración entre dueños de producto, analistas de negocio y testers: cómo se escriben los criterios de aceptación y las pruebas de aceptación junto con el negocio, y cómo se lleva a cabo la aceptación.
Pruébalo
¿Qué hallazgo es este?
La idea
Por qué «no es esto» llega tan tarde
La historia de la contadora es un clásico. Los requisitos eran correctos y completos para el descuento. Nadie había preguntado a contabilidad qué hace después con los descuentos. La parte interesada a la que nadie pregunta aparece en la aceptación.
Las causas suelen ser las mismas:
- el requisito se anotó como una solución («un campo de código en el carrito») y no como una necesidad;
- las personas que van a trabajar con el sistema no estuvieron en las reuniones;
- nadie observó el proceso de trabajo, solo se preguntó por él;
- la primera respuesta del negocio llega recién con el sistema terminado.
Lo último es lo más caro. En la aceptación todo está construido, y cada cambio es retrabajo. Tres días antes del lanzamiento quedan dos malas opciones: lanzar sin lo necesario o aplazar.
La idea
La demo y el prototipo
La respuesta es que la retroalimentación llegue antes, mientras un cambio es barato:
- un prototipo: un boceto o una página por la que se puede hacer clic, sin lógica real. La contadora ve la pantalla del pedido antes de la primera línea de código y dice: «¿dónde está mi código?». Cuesta una hora;
- una demo: al final de cada sprint el equipo muestra la parte que funciona a las personas que la van a usar. Lo mejor es que no solo miren, sino que prueben ellas mismas una tarea real;
- acceso temprano: un grupo pequeño del negocio trabaja con las partes terminadas mientras se construyen las demás.
La demo y el prototipo no sustituyen a la aceptación. Hacen que en la aceptación no haya sorpresas, solo confirmación. Es la misma idea que shift-left: la comprobación se adelanta, porque ahí es más barata.
Más precisamente, para curiosos
En Scrum la demo ocurre en la revisión del sprint (sprint review): el equipo presenta los resultados a las partes interesadas clave, y juntos discuten qué hacer a continuación. La Guía de Scrum llama a la revisión una sesión de trabajo que no debe limitarse a una presentación.
Pruébalo
De la retroalimentación más barata a la más cara
Ordena los lugares donde el negocio puede decir «no es esto», del más barato al más caro.
Pruebas de aceptación con trabajo real antes del lanzamientoUn prototipo por el que se puede hacer clic, sin código realUna demo de una parte que funciona al final del sprintUna queja de un cliente después del lanzamientoUn boceto en papel en la pizarra con la historia
Un boceto cuesta minutos, un prototipo horas, una demo una semana de trabajo. En la aceptación todo está construido, y después del lanzamiento el error ya está con los clientes.
Ejercicio
Aceptación de los códigos promocionales
1. El plan. Los códigos promocionales están listos para la aceptación.
Test