Lunes, 9 de la mañana. La regresión nocturna tiene 47 tests en rojo. Nadie tocó la lógica de negocio: alguien de frontend renombró una clase CSS y reordenó dos divs en el formulario de alta. La app funciona perfecto. Los tests, no.
Cualquiera que haya mantenido una suite de automatización conoce esta escena. Y conoce el costo real: no son los 47 tests, es la mañana entera de alguien del equipo actualizando selectores en vez de probar lo que acaba de salir.
El self-healing promete resolver exactamente esto. El problema es que la mayoría de las implementaciones atacan el síntoma y no la causa.
En este artículo contamos cómo lo encaramos en Qualis Lab, y cómo lo aplicamos en Tessa, nuestra plataforma de automatización inteligente.
Qué es el self-healing, y qué no es
Self-healing es la capacidad de un framework de automatización de detectar que un elemento de la interfaz cambió, encontrar su nueva versión y seguir ejecutando el test sin intervención manual.
Lo que no es: una herramienta para que los tests pasen. Esa diferencia parece sutil y es la más importante de todo el artículo.
Un self-healing mal diseñado es peligroso, porque puede convertir un bug real en un test verde. Si el botón "Confirmar pago" desapareció y el mecanismo de recuperación encuentra "Cancelar" en la misma posición, hace clic y sigue, el reporte dice que todo está bien. No está bien. Acabás de automatizar la ceguera.
Por eso nuestra regla de base es simple: el self-healing puede cambiar cómo se encuentra un elemento, nunca qué elemento se busca ni qué hace el test.
Por qué la mayoría de los enfoques se quedan cortos
La forma más común de "curar" un test es guardar una lista de locators alternativos. Si falla el id, probá con el name; si falla el name, probá con el XPath; si falla el XPath, probá con el texto.
Funciona para cambios chicos. Para todo lo demás, no, y la razón es estructural: el framework solo sabe lo que guardaste. Si en el momento de construir el test registraste un selector, cuando ese selector se rompe no tenés información para decidir cuál de los veinte botones de la pantalla es el que buscabas.
El problema no está en la ejecución. Está en lo que el framework sabe del elemento.
Nuestra visión: el framework tiene que saber qué está buscando
Cuando una persona busca un botón en una pantalla que cambió, no memoriza su id. Sabe que es el botón de confirmar, que está dentro del modal de pago, abajo del campo del monto, al lado de "Cancelar", en el paso tres del checkout. Si el botón se movió o cambió de color, lo encuentra igual.
Un framework con self-healing real tiene que razonar de la misma forma. Y para eso tiene que tener la misma información.
Por eso, en los frameworks que construimos, cada ejecución exitosa guarda mucho más que un selector. Cuando un test pasa, el framework registra cómo era el elemento en ese momento y lo usa como línea base:
- Contexto de página: URL, título y en qué parte del flujo funcional está la acción.
- Contexto del elemento: su estructura en el DOM, su jerarquía, sus atributos, su texto visible.
- Contexto de vecindad: qué elementos lo rodean, en qué contenedor, formulario o modal vive.
- Contexto funcional: qué paso del escenario ejecuta esa acción, y en qué página, modal o sección ocurre.
No importa cómo se escribió el test: a mano con Page Objects, con Screenplay o generado por un recorder. El contexto se construye ejecución tras ejecución. Y si el test se genera grabando un flujo, esa misma captura puede arrancar la línea base desde el primer día.
Con esa información, cuando un elemento cambia, la pregunta deja de ser "¿qué selector alternativo pruebo?" y pasa a ser "¿cuál de los elementos de esta pantalla es, con más probabilidad, el mismo que funcionaba en la última ejecución exitosa?". Es una pregunta que se puede responder con criterio.
Dónde vive esa información importa
Una decisión de arquitectura que parece menor y no lo es: la metadata de contexto vive dentro del propio proyecto de automatización, versionada junto al código.
Asociada al elemento, no al paso. Un mismo campo se usa en muchos tests. Si la metadata está en el elemento, se cura una vez y el arreglo impacta en todas las acciones que lo usan.
Versionada en el repositorio. Cada cambio que hace el self-healing queda en el historial, con trazabilidad completa. Sabés qué cambió, cuándo y por qué.
Sin dependencia de plataformas externas. Muchas soluciones comerciales guardan esta información en su propia nube. Funciona, hasta que cambiás de herramienta, se cae el servicio o el cliente tiene restricciones de seguridad sobre dónde puede vivir información de sus aplicaciones. Si el contexto está en tu repo, es tuyo.
Cómo funciona el ciclo
Cuando un test no encuentra un elemento, el proceso es este:
- Detección. El locator principal falla.
- Búsqueda de candidatos. Se analizan los elementos de la pantalla actual que podrían corresponder al original.
- Puntuación por contexto. Cada candidato se compara con la línea base de la última ejecución exitosa: tipo de elemento, texto, jerarquía, vecinos, contenedor, posición en el flujo.
- Decisión según confianza:
- Confianza alta: se aplica el ajuste, el test continúa, el cambio queda registrado y la línea base se actualiza.
- Confianza media: el test continúa, pero el ajuste se propone para revisión humana antes de consolidarlo.
- Confianza baja: el test falla. Como corresponde.
Ese tercer caso es lo que separa un self-healing útil de uno peligroso. Un framework que nunca falla no es robusto: es sospechoso.
Cómo lo aplicamos en Tessa
Tessa es la plataforma de automatización inteligente desarrollada por Qualis Lab, y el self-healing basado en contexto es una de sus piezas centrales. Reúne en un solo flujo tres cosas que en la mayoría de los equipos viven separadas:
Generación de escenarios con IA. Tessa genera los escenarios funcionales en Gherkin, un lenguaje que entienden por igual negocio, desarrollo y QA.
CodeGen propio sobre Playwright. En lugar de usar el grabador nativo, Tessa tiene su propio generador de código. Mientras graba un flujo, captura el contexto completo de cada elemento: DOM, jerarquía, vecinos, contenedor, página y paso funcional. La línea base para el self-healing existe desde la primera grabación, sin esperar ejecuciones.
Runner de ejecución propio. Ejecuta los escenarios de forma manual o integrada al pipeline de CI/CD, recolecta evidencias y devuelve los resultados a la plataforma.
La IA de Tessa es el puente entre el mundo funcional y el técnico. Asocia cada paso Gherkin con las acciones que lo implementan, reutiliza automatización existente antes de crear piezas nuevas y, cuando la interfaz cambia, usa el contexto para proponer o aplicar el ajuste según el nivel de confianza.
Toda la metadata de contexto vive en el repositorio del proyecto, versionada junto al código. Nada queda atado a una nube de terceros.
El resultado: el equipo define qué probar. Tessa se encarga de que la forma de probarlo no se rompa con cada release.
La IA como criterio, no como atajo
La IA tiene un rol concreto en este esquema: interpretar el contexto. Detectar que un campo pasó de llamarse "Nro. de documento" a "DNI" es trivial para un modelo y casi imposible para una regla fija. Lo mismo con un botón que cambió de posición pero sigue siendo, funcionalmente, el mismo.
Lo que no hace la IA es decidir qué debería probar el test. La intención funcional la define el escenario, y el self-healing trabaja siempre subordinado a ella.
Lo que hay que medir
Si implementás self-healing y no medís, perdiste la mitad del valor. Los indicadores que miramos:
- Curaciones por ejecución. Cuántos elementos se recuperaron automáticamente.
- Tasa de aceptación. De los ajustes propuestos, cuántos se aprobaron y cuántos se rechazaron. Muchos rechazos indican que el umbral de confianza está mal calibrado.
- Elementos reincidentes. Un elemento que se cura en cada release es una señal: o la interfaz es inestable, o el locator original está mal elegido. En ambos casos, es una conversación para tener con desarrollo.
- Horas de mantenimiento evitadas. El número que le importa al negocio.
Lo que el self-healing no reemplaza
No reemplaza las buenas prácticas de diseño de locators. Un equipo de desarrollo que agrega atributos estables como data-testid en los elementos críticos le ahorra trabajo a cualquier mecanismo de recuperación.
No reemplaza la comunicación entre QA y desarrollo. Un rediseño completo de una pantalla no es un caso de self-healing: es un cambio funcional que requiere revisar los escenarios.
Y no reemplaza el criterio del equipo. Es una herramienta para que las personas dejen de hacer trabajo repetitivo, no para que dejen de mirar.
En resumen
La mayoría de los tests no se rompen porque la aplicación falla. Se rompen porque el framework no sabe lo suficiente sobre lo que está buscando.
El self-healing que funciona no empieza cuando el test falla. Empieza mucho antes, en cada ejecución que pasa: si el framework guarda contexto y no solo selectores, tiene con qué razonar cuando la interfaz cambia. Y si ese contexto vive en tu repositorio, versionado y trazable, el control sigue siendo tuyo.
Tessa es la plataforma de automatización inteligente de Qualis Lab: escenarios generados con IA, CodeGen propio sobre Playwright y self-healing basado en contexto, para reducir el mantenimiento sin resignar confiabilidad en los resultados.
Si tu equipo pasa más tiempo arreglando tests que escribiendo tests nuevos, en un diagnóstico gratuito de 20 minutos te mostramos cómo funcionaría Tessa sobre tu aplicación. Conocé Tessa o agendá un diagnóstico.