Las pruebas de aceptación de usuario (UAT) tienen una forma reconocible. Le das a un grupo de personas (empleados internos, el equipo de un cliente, un puñado de clientes beta) acceso a un build y una semana para probarlo. Al final recibes una hoja de cálculo.
La hoja tiene sesenta filas. Quizá quince se pueden atacar de inmediato. Veinte son los mismos tres bugs descritos de cinco formas distintas. Diez describen algo que funciona tal como se diseñó. Diez necesitan una pregunta de seguimiento antes de que nadie pueda empezar. Y cinco dicen algo como «intenté guardar y no guardó», sin indicar qué página, qué navegador ni qué día.
Lo instintivo es culpar a la formación. Escribir una plantilla mejor, dar una sesión sobre cómo reportar bien los bugs, exigir pasos para reproducir. Ayuda un poco, y el efecto se pierde en dos semanas.
Se pierde por una razón estructural. Los testers de UAT no son ingenieros de QA, y pedirles que se comporten como tales es pedir algo que el planteamiento no sostiene.
Por qué los testers reportan de menos
Tres limitaciones, y ninguna tiene que ver con el esfuerzo.
No pueden ver la evidencia. Un tester de UAT no tiene las DevTools abiertas. No sabe que una petición devolvió un 500. Ve un spinner que nunca se detuvo y anota «se congeló». La información que resolvería el bug en noventa segundos estaba en su pantalla, detrás de un atajo de teclado que nadie le enseñó.
Reportar cuesta más de lo que parece valer el bug. Un tester que tiene que cambiar a una hoja de cálculo, encontrar las columnas correctas, describir el contexto y hacer una captura de pantalla lo hará para un cuelgue. Para la etiqueta desalineada o el mensaje de error confuso, tomará nota mental y seguirá. Y esos son justo los hallazgos para los que organizaste la ronda de UAT.
Están probando, no documentando. Un tester concentrado está explorando un flujo. Cada interrupción para escribir un reporte rompe esa concentración, así que los reportes se acumulan para el final de la sesión, que es cuando los detalles quedan más lejos y veinte acciones posteriores ya han borrado la reproducción.
Cada una de estas limitaciones es una propiedad del canal de reporte, no de la persona. Cambia el canal y cambia el comportamiento.
Pon el reporte dentro de lo que se está probando
El cambio con más impacto es sacar el reporte de una herramienta aparte y llevarlo a la propia aplicación que se prueba.
Un botón de reporte en la página elimina las tres limitaciones a la vez. No hay cambio de contexto, así que los reportes se envían en el momento del hallazgo en lugar de acumularse para el final. El esfuerzo baja a un clic, así que los hallazgos pequeños también se reportan. Y el navegador está ahí mismo, así que la evidencia se adjunta sin que el tester sepa qué es evidencia.
Eso es lo que hace una herramienta basada en un widget. BugDump se instala con una sola etiqueta script en el build de staging:
<script src="https://bugdump.com/sdk/latest.js" data-api-key="your-api-key"></script>El tester hace clic, escribe «intenté guardar y no guardó» y lo envía. Lo que llega es esa frase junto con el log de consola, incluido todo lo que se registró antes de abrir el widget, las peticiones de red con estados y tiempos, una repetición de sesión, sus clics y entradas en orden, y su navegador, sistema operativo, viewport y URL.
El tester no aprendió a reportar mejor. El canal dejó de tirar la evidencia.
Configúralo pensando en una ronda de UAT
Algunas decisiones de configuración importan más en pruebas que en producción.
Identifica a tus testers. En producción quizá no sepas quién reporta. En UAT lo sabes siempre, y vale la pena conectarlo: llama a identify() con el nombre y el email del tester, y a setContext() con su rol asignado, su cuenta de pruebas y el escenario que le tocó. Cuando llegan cuatro reportes sobre permisos, ver que los cuatro vienen de testers con el rol de solo lectura ya es el diagnóstico.
Adjunta el build. Mete el hash del commit o el número de build en el contexto. Una ronda de UAT suele abarcar varios despliegues, y sin ese dato no hay forma de responder «¿sigue roto después del arreglo del martes?».
Haz que el botón sea imposible de pasar por alto. En producción, un botón flotante discreto es lo correcto. En UAT no: usa la burbuja de aviso con un texto que diga lo que quieres, algo más parecido a «¿Encontraste algo? Cuéntanoslo» que a un icono mudo. Los testers que olvidan que la herramienta existe acaban mandando los reportes por email.
Activa los cuerpos de red, a conciencia. Los cuerpos de petición y respuesta son lo más útil que puedes adjuntar y lo más sensible. En un entorno de staging con datos sintéticos, captureNetworkBodies suele ser un sí fácil y elimina toda una clase de preguntas de seguimiento. En una ronda de UAT sobre datos de producción con registros reales de clientes, no lo es: déjalo desactivado o filtra los endpoints que transportan datos personales.
Filtra el ruido. Los entornos de staging son ruidosos. Un networkFilter que descarte los endpoints de polling y un consoleFilter que descarte los mensajes de nivel debug hacen los reportes mucho más legibles, y un reporte legible se clasifica en lugar de quedar para después.
Pide tres cosas, no doce
Con la captura resuelta automáticamente, el formulario debería pedir solo lo que únicamente sabe el tester:
Qué salió mal, con sus palabras
Qué esperaba en su lugar
Con qué frecuencia: la primera vez, a veces, siempre
Todo lo demás (navegador, sistema operativo, URL, consola, red, tiempos) llega por su cuenta.
Esa tercera pregunta merece defenderse frente a las ganas de quitarla. «Siempre» frente a «a veces» es la diferencia entre un bug determinista y una condición de carrera, y cambia dónde mira un desarrollador antes de haber mirado en ningún sitio. Además, es lo único sobre la frecuencia que ninguna instrumentación puede aportar, porque vive en la memoria del tester sobre los últimos veinte minutos.
Resiste la tentación de añadir un desplegable de gravedad. Todos los testers eligen «Alta», porque desde dentro de un escenario de prueba bloqueado todo parece grave. La frecuencia, junto con cuántas personas lo reportan, hace el mismo trabajo con mejores datos.
Los duplicados son lo que buscas
El reflejo habitual ante una ronda de UAT es pensar que los reportes duplicados son desperdicio: veinte filas que describen tres bugs. Es al revés.
Cinco personas que reportan el mismo botón de guardar roto te dan cinco entornos, cinco secuencias de pasos, cinco logs de red. Si cuatro están en Safari y una en Chrome con un viewport estrecho, tienes la causa antes de que nadie abra el código. Un solo reporte de ese bug te habría dicho mucho menos.
Lo que necesitas no son menos duplicados. Es una estructura en la que los duplicados se apilan en lugar de dispersarse. Ese es justo el motivo por el que BugDump separa los reportes de las tareas: un reporte es la evidencia de una persona, una tarea es lo que de verdad corriges, y muchos reportes se adjuntan a una tarea. Veinte reportes se convierten en seis tareas, cada una con toda su evidencia, y las veinte filas dejan de ser desorden para convertirse en una matriz.
Los testers pueden adjuntar su propio reporte a una tarea existente por su ID público si activas allowTaskAttach, y así «seguro que alguien ya lo reportó» deja de ser un motivo para no reportar y se convierte en una confirmación de un clic de que a ellos también les pasa.
Cierra el ciclo o la ronda muere
La forma más segura de acabar con la participación en una ronda de UAT es el silencio. Un tester que envía seis reportes la primera semana y no recibe respuesta envía cero la segunda. No por despecho: ha aprendido que reportar no sirve de nada, y tiene razón.
Dos cosas lo arreglan, y las dos son baratas.
Lleva los reportes adonde ya está el equipo. Un canal de Telegram, Slack o Discord que recibe un mensaje por reporte hace que la ronda se sienta viva para todos, testers incluidos. Si los bugs deben convertirse en issues, una integración con GitHub Issues o Jira evita que alguien tenga que copiar a mano la hoja de cálculo en un tracker.
Dales a los testers una página de estado. Un portal público donde quien reporta ve cómo su tarea pasa de Confirmado a Hecho es todo el mecanismo. Quien ve que su reporte se corrige envía el siguiente, y lo envía en la tercera semana, que es cuando salen a la luz los bugs interesantes.
Cómo queda al final de la ronda
La hoja de cálculo se sustituye por un tablero. Sesenta reportes se han reducido a un par de docenas de tareas, cada una con la evidencia de todos los que se toparon con el bug. Las filas inservibles han desaparecido, porque los campos que las hacían inservibles los rellenó el navegador y no una persona adivinando qué importaba.
El trabajo del tester volvió a ser lo que debía ser: usar el software y decir qué le pareció mal. Averiguar qué significa eso es trabajo del desarrollador, y ahora tiene lo que necesita para hacerlo.
El plan Gratis de BugDump cubre 500 reportes al mes por proyecto sin tarjeta, más de lo que produce la mayoría de las rondas de UAT, así que instálalo en el build de staging el día antes de que empiecen las pruebas.
Te puede interesar
Cómo recopilar reportes de bug de tus beta testers sin perder la mitad — un widget dentro del producto, contexto capturado automáticamente y un triaje que responde al tester.
Reportes de bug de los clientes: una configuración para agencias web — un widget en cada web de cliente en lugar de hilos de email, con un tablero por proyecto.
De 40 reportes a 6 bugs: cómo debería funcionar el triaje — por qué separar reportes y tareas convierte los duplicados en tu mejor material de depuración.