El equipo de Dokumenterra encarga a Claude escribir pruebas automatizadas en cinco horas

Tras lanzar una función, hay que volver a describir su comportamiento para quien la va a probar y después convertir los escenarios en pruebas automatizadas. En Dokumenterra probaron a utilizar la documentación del producto para ello: Claude la lee, elabora casos de prueba y escribe las pruebas. El ejemplo del restablecimiento de contraseña muestra qué produce el proceso y en qué puntos una persona debe comprobar las suposiciones del modelo.

Según el director de tecnología de la empresa, preparar los prompts para una función lleva una hora; después, Claude trabaja otras cinco horas. Es una estimación del propio equipo. El artículo no ofrece una comparación con el desarrollo manual de pruebas, los costes de ejecución ni estadísticas de errores, por lo que todavía no se puede calcular la mejora.

De las instrucciones a dos pruebas

En el ejemplo, el agente recibe unas instrucciones para restablecer la contraseña: abrir la página de inicio de sesión, seguir el enlace de recuperación, introducir el nombre de usuario o el correo electrónico y solicitar un mensaje. Lee la documentación mediante MCP, una conexión que permite acceder a herramientas de búsqueda y lectura de páginas.

Claude convierte las instrucciones en dos escenarios. El primero comprueba que el enlace de la página de inicio de sesión abre el formulario de recuperación. El segundo verifica que dejar vacío el nombre de usuario genera un error de validación y que el usuario permanece en la misma página. Después genera pruebas automatizadas que comprueban la URL de la página, la visibilidad de los campos y el mensaje de error.

El segundo escenario tiene un detalle importante: las instrucciones originales no dicen nada sobre un campo vacío. El modelo propuso por su cuenta el comportamiento esperado. Es un punto de partida útil para quien realiza las pruebas, pero debe contrastarse con los requisitos del producto. Una suposición plausible no se convierte en una regla solo porque un agente la haya plasmado en una prueba.

El código mostrado también se apoya en fixtures existentes y en el objeto de página ForgotPasswordPage. Por tanto, el ejemplo no demuestra la creación de toda la infraestructura de pruebas desde cero. Además, estas dos comprobaciones no abarcan todo el proceso de restablecimiento de contraseña: recibir el correo, seguir su enlace y establecer una contraseña nueva.

Dos revisiones siguen en manos de las personas

El equipo describe dos etapas manuales obligatorias. Primero, una persona revisa la documentación y después los casos de prueba elaborados por el modelo. A continuación, supervisa la creación de las pruebas automatizadas.

La primera revisión protege frente a requisitos desactualizados. Si las instrucciones describen un comportamiento que ya ha cambiado en el producto, el agente puede reproducir fielmente el error en los escenarios. En ese caso, una ejecución con todas las pruebas en verde indicará que se cumple una expectativa incorrecta.

La segunda revisión sirve para comprobar la cobertura. Un especialista que conozca a los usuarios puede detectar condiciones, roles o excepciones que falten. En el ejemplo del restablecimiento de contraseña, también conviene plantearse qué escenarios hacen falta para un enlace caducado y una nueva solicitud del correo. Son posibles incorporaciones al plan de pruebas; el artículo no muestra que el equipo las haya implementado.

El propio autor advierte de que el servidor MCP se utiliza desde hace poco y los resultados son preliminares. Tampoco se ha verificado cómo se maneja la información de las capturas de pantalla. El servidor devuelve Markdown con enlaces a imágenes, pero el equipo todavía no ha determinado si el agente extrae de ellas la información necesaria.

Qué puede adoptar tu equipo

El valor práctico del caso está en la organización del proceso. El agente recibe la descripción de una función, una tarea, un PR y los casos de prueba existentes, busca la documentación por su cuenta y después propone un plan de pruebas. Así, quien realiza las pruebas dispone de material concreto para revisar.

Las restricciones precisas resultan especialmente útiles en este proceso. Indicar que se admite la subida de archivos apenas define los resultados esperados. Especificar el tamaño máximo y un error concreto ya permite diseñar pruebas de valores límite. Si una regla admite varias interpretaciones, primero hay que acordar el comportamiento y después fijarlo en una prueba.

En este caso, MCP permite acceder a las páginas actuales, incluido el contenido restringido si se dispone de los permisos necesarios. Sin embargo, el relato no demuestra que el enfoque sea imposible sin esa conexión: para un pequeño experimento, se puede proporcionar al agente un fragmento seleccionado de la documentación. La propia conexión tampoco garantiza que el texto esté actualizado y sea correcto.

Se puede empezar con una sola función: revisar su descripción, obtener escenarios, acordar los resultados esperados y solo entonces generar código. Para evaluar los beneficios, conviene medir el tiempo de preparación y revisión, el número de correcciones y la estabilidad de las pruebas ante cambios posteriores. El caso de Dokumenterra ofrece un esquema reproducible para este experimento, pero todavía no demuestra que cualquier equipo vaya a ahorrar recursos.