Gran parte del trabajo de un QA estuvo concentrado en tareas necesarias pero altamente operativas: leer documentación, interpretar requerimientos, diseñar casos de prueba, documentarlos, preparar datos y mantener regresiones.
La incorporación de inteligencia artificial aplicada al ciclo de testing no busca reemplazar al QA, sino permitirle dedicar más tiempo a las actividades donde realmente aporta valor: analizar riesgos, explorar comportamientos, detectar problemas complejos y mejorar la calidad del producto.
Fue precisamente para resolver este desafío que nació TESSA. Su propósito no es reemplazar el criterio del tester, sino potenciarlo: automatiza las tareas repetitivas y acelera la generación de activos de testing —casos de prueba, escenarios en Gherkin, validaciones de interfaz y automatización de los casos— para que los equipos de QA puedan concentrarse en el análisis, la cobertura funcional y la prevención temprana de defectos.
Pero, ¿qué cambia realmente en el día a día de un tester? ¿Cuánto más puede producir un QA durante una jornada de trabajo utilizando TESSA? Para responderlo, comparemos una jornada laboral de ocho horas haciendo exactamente el mismo trabajo: primero de forma tradicional y después con TESSA.
El punto de partida: son las 9:00
Un QA recibe una nueva funcionalidad para validar. Como todos los días, tiene por delante un desafío: transformar un requerimiento funcional en una batería de casos de prueba que permita asegurar la calidad del producto antes de llegar a los usuarios finales.
La información que recibe es la misma para cualquier escenario:
- Una historia de usuario.
- Criterios de aceptación.
- Reglas de negocio.
- Flujos funcionales.
- Diseños de interfaz cuando corresponde.
Su objetivo es claro: entender qué debe validarse y diseñar los casos de prueba necesarios para cubrir la funcionalidad. La única diferencia es si trabaja de manera tradicional o con TESSA como asistente.
El día de un QA trabajando de manera manual
A las 9:00 comienza el análisis del requerimiento. El primer paso es entender la funcionalidad: leer la documentación, interpretar las reglas de negocio, analizar los criterios de aceptación e identificar los escenarios que deberían validarse. Esta etapa le lleva aproximadamente 1 hora.
Una vez comprendido el requerimiento, comienza la etapa más importante: transformar ese conocimiento en casos de prueba. Cada caso requiere pensar y documentar:
- Nombre del caso.
- Objetivo.
- Precondiciones.
- Datos necesarios.
- Pasos de ejecución.
- Resultado esperado.
- Validaciones adicionales.
Además, el QA debe contemplar diferentes caminos: escenarios positivos, escenarios negativos, validaciones alternativas y casos borde.
Según las métricas relevadas, diseñar un caso de prueba de manera manual demanda aproximadamente 30 minutos por caso. Luego del análisis inicial le quedan 7 horas para diseñar:
210 minutos disponibles / 30 minutos por caso
= 14 casos de prueba por día
Al finalizar la jornada, este QA logró construir aproximadamente 14 casos de prueba. Es un trabajo detallado, que depende mucho del tiempo disponible y de la experiencia del profesional para detectar todos los escenarios posibles.
El día de un QA utilizando TESSA
Ahora imaginemos el mismo escenario. Son las 9:00 y el QA recibe exactamente el mismo requerimiento. La diferencia es que cuenta con TESSA como asistente durante el proceso de diseño.
El QA carga la información y comienza a trabajar sobre la funcionalidad. TESSA lo ayuda a analizar el requerimiento, identificar escenarios y proponer una primera cobertura de pruebas, evitando la lectura completa de documentación y la interpretación manual de reglas y criterios de aceptación. El QA sigue siendo quien toma las decisiones, valida los escenarios y aporta el conocimiento del negocio, pero ya no comienza desde una hoja en blanco.
Después del análisis inicial llega el momento de generar los casos. La métrica obtenida muestra una diferencia significativa: los escenarios de prueba generados con TESSA demoraron aproximadamente 2 min 20 seg, lo que permite tener la primera versión de los casos disponible casi de inmediato.
Sin embargo, el trabajo del QA no desaparece. La persona sigue teniendo un rol fundamental:
- Revisar los casos generados.
- Ajustar reglas particulares del negocio.
- Eliminar escenarios repetidos.
- Agregar conocimiento funcional.
En lugar de dedicar una jornada completa al diseño, el QA obtiene una primera versión en pocos minutos y puede invertir el resto del tiempo en revisar, enriquecer y validar la cobertura funcional. Esto permite iniciar las pruebas prácticamente en paralelo con el desarrollo, detectar defectos de forma más temprana y acelerar todo el ciclo de aseguramiento de la calidad.
El impacto de TESSA en números
Para calcular una productividad realista diaria, consideramos un promedio de 5 minutos adicionales de revisión y ajuste de todos los escenarios luego de la primera versión de TESSA. Como el QA se ahorró el análisis inicial, contó con 8 horas disponibles para el diseño.
| Jornada de 8 horas | Manual | Con TESSA |
|---|---|---|
| Análisis inicial | 1 hora | Asistido por TESSA |
| Tiempo por caso | 30 minutos | ~5 minutos de revisión |
| Casos al final del día | 14 | 96 |
Esto significa 6,9 veces más capacidad operativa con la misma jornada laboral y el mismo recurso, y un 85% de reducción en el tiempo y el costo necesarios para generar cada caso.
¿Querés ver cómo funciona sobre tus propios requerimientos? Conocé TESSA o escribinos y lo vemos juntos.