Pruebas de aceptación de software hecho por un proveedor

Pagaste a una agencia, a un contratista o a un equipo deslocalizado para construir algo. Ya está entregado. La demo salió bien.

Ahora: ¿cómo sabes que funciona?

Esta es una posición incómoda que ocupan muchísimas organizaciones y de la que pocas hablan. No tienes el código fuente, o tienes derechos sobre él que no puedes usar. Nadie dentro de tu organización podría leerlo aunque lo tuvieras. El proveedor dice que está terminado y espera el visto bueno, y la única evidencia que tienes es una demostración que controlaba él.

Por qué el consejo habitual no sirve aquí

La orientación estándar sobre testing da por supuesto que eres dueño del código y que empleas a gente que lo entiende. Escribe tests unitarios, sube la cobertura, conéctalo a CI. Nada de eso está disponible aquí, y proponérselo a un comprador en esta situación no es útil.

Lo que sí tienes vale más de lo que parece: sabes qué se supone que hace el software. Tú lo especificaste. Ese es exactamente el conocimiento que exigen las pruebas de aceptación, y es un conocimiento que el proveedor no puede aportar en tu nombre.

Escribe los criterios antes de la entrega

Lo que más partido te va a dar no cuesta nada y ocurre antes de que exista una línea de código: escribe tus criterios de aceptación como flujos concretos.

Un criterio utilizable nombra tres cosas: un estado inicial, una acción y un resultado observable.

Como cliente con un artículo en la cesta, completar la compra con una tarjeta válida produce un correo de confirmación del pedido y un pedido visible en el historial de la cuenta.

Compáralo con lo que contienen en realidad casi todos los contratos: «el proceso de compra debe funcionar correctamente». Lo primero puede verificarlo alguien mirando una pantalla. Lo segundo es una discusión esperando a ocurrir.

La prueba de un buen criterio es sencilla. Si no puedes comprobarlo mirando la aplicación, no es un criterio de aceptación. Puede ser un requisito legítimo —objetivos de rendimiento, postura de seguridad, calidad del código— pero necesita otro tipo de verificación y debería tratarse aparte.

Entre quince y treinta de estos cubren la mayoría de los proyectos encargados. Adjúntalos al contrato.

Verifícalos tú

No aceptes una demostración como evidencia. Una demo es un recorrido ensayado por el software, ejecutado por quienes lo construyeron, con los datos que ellos eligieron. Te dice que el camino feliz funciona un martes.

Ejecuta los criterios tú, contra la aplicación entregada, en un sistema que controles, con datos que elijas tú. Como el testing end-to-end funciona a través de la interfaz, esto no requiere acceso al código ni más colaboración que una URL y unas credenciales.

Tres cosas que conviene comprobar y que los proveedores rara vez demuestran:

• Los caminos infelices. Una tarjeta caducada. Un correo duplicado. Un campo obligatorio en blanco. Aquí es donde el software encargado es más flojo, porque es donde la especificación era más delgada.
• Los permisos. Inicia sesión como un cliente e intenta llegar a los datos de otro. Este es el fallo que se convierte en una obligación de notificación.
• La segunda vez. Ejecuta el mismo flujo dos veces. El software que da por supuesto un estado limpio se rompe con frecuencia en la repetición.

Conserva los tests después del visto bueno

Las pruebas de aceptación suelen tratarse como un acontecimiento: verificar, firmar, pasar página. Eso desperdicia la mayor parte de su valor.

Los criterios que escribiste son una suite de regresión. Si el proveedor se queda con un contrato de mantenimiento, ahora describen lo que no debe romperse en el trabajo futuro. Si no se queda, y el software pasa dos años sin tocarse, la suite es cómo te enteras de que una actualización del navegador, un certificado caducado o un cambio de proveedor de pagos rompió algo que nadie vigilaba.

El coste de mantenerlos en marcha es pequeño. El coste de descubrir por un cliente una avería de hace dos meses no lo es.

Cuando algo falla

Informa de los fallos como reproducciones, no como opiniones. «La compra está rota» es discutible; un flujo concreto con datos concretos, ejecutado dos veces y con el resultado registrado, no lo es. Traslada la conversación de si hay un problema a cuándo se va a arreglar.

Esto vale más de lo que parece en una relación comercial. Los proveedores no suelen actuar de mala fe: trabajan a partir de una especificación que era más vaga de lo que ninguna de las dos partes creía. Unos criterios concretos y reproducibles eliminan la ambigüedad que convierte una entrega en una disputa.

Herramientas que encajan en esta situación

El requisito es poco habitual y estrecha mucho el campo: la herramienta debe funcionar contra una aplicación que no puedes modificar, sin acceso al código, sin pipeline de build y probablemente sin ingenieros.

Eso elimina los frameworks basados en código, todo lo que exija CI y la mayoría de las plataformas de QA. Lo que queda son herramientas que solo necesitan una URL y una descripción del flujo: Testmode, testRigor, Rainforest QA, Functionize y Autify.

Escribir en lenguaje natural importa aquí más de lo habitual, por un motivo concreto: la persona que sabe qué se encargó es la que escribió la especificación, no un desarrollador. Si escribir el test exige código, el conocimiento y la capacidad están en cabezas distintas, y algo se pierde en el traspaso.

Consulta el resumen de herramientas de testing con IA para el panorama completo, ordenado por lo que cada una necesita de ti, y testing de regresión sin equipo de QA para saber qué hacer con la suite después del visto bueno.