Por Ignacio Muñoz, Project Manager ACL
La conversación sobre IA en testing suele partir por el lugar equivocado: herramientas primero, proceso después.
Para QA, el orden útil es otro. Primero hay que aclarar dónde entra la calidad dentro del ciclo de desarrollo. Después recién tiene sentido decidir qué parte conviene reforzar con IA.
Si QA sigue entrando tarde, la IA no resuelve el problema de fondo. Solo acelera trabajo que ya llegó tarde.
Para ordenar el mapa, conviene apoyarse en dos marcos simples: el ciclo de vida del software definido en ISO/IEC/IEEE 12207 y la familia ISO/IEC/IEEE 29119 para testing. El primero describe cómo se desarrolla y mantiene software. El segundo organiza el ciclo de pruebas: análisis, planificación, diseño, ejecución y cierre.
La relación entre ambos es directa: el STLC se ejecuta dentro del SDLC. Y QA con IA aporta cuando mejora ese encaje. No cuando se suma como una capa aislada de productividad.
Eso explica bien por qué la propuesta de QA con IA de ACL pone el foco en el ciclo completo: mejorar historias, reforzar criterios de aceptación, fortalecer regresión y entregar una señal de calidad más útil a lo largo del delivery.
El SDLC organiza el desarrollo: requerimientos, diseño, construcción, pruebas, release y mantenimiento.
El STLC organiza el trabajo de testing dentro de ese recorrido: análisis, planificación, diseño de casos, preparación de ambientes y datos, ejecución y cierre.
No compiten. Se complementan.
La razón por la que esto importa es simple: muchas iniciativas de IA en QA generan más artefactos, pero no necesariamente mejores decisiones. Más casos no significa mejor cobertura. Más automatización no significa mejor señal.
Aquí suele aparecer el valor antes y con menos riesgo.
En requerimientos, el aporte no es “escribir más casos”. Es mejorar la calidad del input: historias más claras, criterios más testeables, menos ambigüedad. Con IA, QA puede revisar historias y detectar:
Esto no reemplaza el refinamiento. Lo mejora. Y reduce retrabajo aguas abajo.
ACL lo muestra bien en su guía sobre QA con IA: transformando el testing de software: el impacto real no suele venir de “automatizar por automatizar”, sino de mejorar foco, trazabilidad y calidad de decisión.
En ese mismo artículo, ACL comparte un caso breve que aterriza el punto justo donde más duele. El cuello de botella estaba en el diseño manual de casos: construir una matriz completa desde historias de usuario tomaba horas por funcionalidad, y la ambigüedad en criterios de aceptación generaba retrabajo entre Product Owner y QA.
¿Qué cambió? Se incorporó un asistente de IA para dos tareas concretas: proponer casos de prueba desde historias y apoyar al Product Owner en mejorar redacción y criterios antes de que el trabajo llegara a QA. El resultado observado fue pasar de horas de armado inicial a revisión en minutos, liberando tiempo para pruebas de mayor valor y mejorando la consistencia de criterios. El aprendizaje útil del caso no es solo “la IA ahorró tiempo”. Es otro: el impacto apareció cuando se estandarizó el input y se gobernó la salida con revisión QA.
Ese detalle importa porque es el tipo de problema que un QA Lead o un Engineering Manager reconoce rápido: si el trabajo entra desordenado, la IA no lo ordena por sí sola.
En diseño, QA con IA ayuda a evitar un error bastante común: cubrir tarde y por inercia.
Puede apoyar en:
Aquí sigue siendo útil la lógica de la Practical Test Pyramid: si casi todo cae en E2E, el costo sube y la confiabilidad suele bajar.
Y si quieres una guía más operativa, el artículo de ACL sobre tipos de testing ayuda a ordenar qué prueba cumple qué función dentro del ciclo.
Durante desarrollo, el valor aparece cuando QA con IA se acerca al cambio real y no espera a la fase “testing”.
La IA puede apoyar en:
Pero hay una frontera que conviene dejar clara: la IA puede sugerir. La decisión sigue siendo del equipo. La pregunta importante no es “¿puede generar un caso?”. La pregunta es otra: ¿ese caso cubre un riesgo real y vale su costo de mantenimiento?
Esa diferencia suele separar una suite sana de una suite que se vuelve un lastre.
En ejecución, QA con IA sirve para recuperar tiempo donde más se pierde: interpretar ruido.
Casos típicos:
En equipos con CI/CD, el dolor real rara vez es “falta de pruebas”. Más seguido aparece otra cosa: falta de confianza en el sistema de pruebas. Cuando la suite es lenta o inestable, QA deja de leer riesgo y pasa a hacer triage de ruido.
En release, QA con IA no debería decidir. Debería ordenar evidencia.
Puede ayudar a:
La decisión final de salida sigue siendo humana, porque ahí no solo hay datos: también hay contexto, trade-offs y responsabilidad.
Esta etapa suele quedar fuera del discurso, pero es donde más se nota si QA con IA fue superficial o serio.
Aquí la IA puede ayudar a:
Si lo que ocurre en producción no retroalimenta el STLC, el equipo repite errores y la IA solo optimiza tareas aisladas.
Cómo se ve dentro del STLC
Etapa del STLC
Dónde ayuda la IA
Qué sigue siendo responsabilidad del equipo
Análisis
detectar vacíos y ambigüedades
validar contexto, riesgo y criterios
Planificación
apoyar priorización y alcance
definir estrategia y umbrales
Diseño
generar borradores y datos
revisar cobertura útil y trazabilidad
Preparación
sugerir datasets y dependencias
consistencia, seguridad y compliance
Ejecución
resumir logs, agrupar fallos
causa raíz, severidad e impacto
Cierre
consolidar tendencias
decisiones, deuda y acciones
La lectura práctica es esta: si el STLC es difuso, la IA no lo corrige. Lo amplifica.
El punto incómodo: si tu sistema de trabajo está desordenado, la IA lo amplifica
Esto aplica directo a herramientas como Jira. Si las historias vienen con criterios disparejos, evidencia incompleta y workflows inflados, activar IA encima no ayuda. Amplifica inconsistencias.
ACL lo baja bien en Estandarizar Jira para aprovechar la IA: orden antes de automatizar: primero estándar y gobierno, después automatización.
Esa idea conversa muy bien con QA porque el problema casi nunca es solo la herramienta. Es la calidad del sistema de trabajo que la rodea.
Qué conviene delegar a IA y qué no
Conviene usar IA para:
- Revisar historias y criterios en busca de vacíos;
- Generar borradores de casos;
- Resumir resultados;
- Detectar patrones;
- Apoyar mantenimiento de scripts.
No conviene delegarle por completo:
- La estrategia de calidad;
- El criterio de riesgo;
- La decisión de release;
- La validación final de datos sensibles;
- La priorización entre cobertura, deuda y velocidad.
Este marco conversa bien con el AI Risk Management Framework de NIST y con ISO/IEC 42001: IA con estructura, responsabilidad y control, no como caja negra.
Dónde conviene partir y dónde no
Un punto de entrada sano suele ser este:
- Revisar historias y criterios,
- Generar borradores de casos,
- Validar con QA y desarrollo,
- Reforzar regresión o integración con evidencia más limpia.
¿Por qué ahí? Porque tiene valor rápido y riesgo acotado. Mejora el input y reduce retrabajo.
En cambio, partir pidiéndole a la IA que “automatice la regresión completa” suele salir mal. Si no hay estrategia, trazabilidad y suites relativamente estables, lo que escala no es la calidad. Es el ruido.
En la landing de QA con IA de ACL se ve bien ese enfoque: primero mejorar señal, criterios y trazabilidad; después expandir.
Riesgos típicos, y por qué importan en Chile
Los riesgos más comunes no suelen venir del modelo en sí. Suelen venir del uso que se le da dentro del proceso:
- datos productivos usados sin anonimización,
- decisiones automatizadas sin rastro auditable,
- ambientes mezclados sin controles claros,
- workflows donde nadie sabe quién valida qué.
En Chile, esto se vuelve más sensible con la Ley 21.719, que eleva exigencias sobre tratamiento y control de datos personales.
Y si QA con IA se integra a CI/CD, también conviene mirar prácticas de seguridad del pipeline como la OWASP Web Security Testing Guide, los OWASP Top 10 CI/CD Security Risks y la guía de secure use de GitHub Actions.
Checklist rápido de “estamos listos”
- ¿QA participa desde requerimientos?
- ¿Los criterios de aceptación son claros y testeables?
- ¿Existe estrategia por tipo de prueba?
- ¿Hay trazabilidad entre requerimiento, prueba y resultado?
- ¿Los datos de prueba están controlados?
- ¿Hay validación humana de toda salida generada por IA?
- ¿Se mide señal —ruido, flakiness, tiempo de feedback— y no solo volumen?
- ¿Hay ownership claro entre QA, desarrollo y liderazgo?
Si varias respuestas son “no”, el primer paso no es comprar tecnología. Es ordenar el sistema.
QA con IA no vale por “usar IA”, sino cuando mejora el punto donde hoy se pierde más tiempo y más señal.
En la práctica, el patrón que más se repite en implementaciones que escalan no es usar más herramientas. Es otro: mejorar el input, gobernar la salida y reforzar la señal de calidad para decidir. El caso breve de ACL lo muestra bien: el salto vino de estandarizar historias y criterios, y de revisar con QA, no de dejar a la IA “sola”.
Si tu equipo ya tiene síntomas como criterios débiles, retrabajo entre producto y QA, suites que generan más ruido que claridad o decisiones de release tomadas con información fragmentada, probablemente sí vale evaluar una estrategia de QA con IA.
Si todavía no tienes trazabilidad mínima, estrategia de pruebas ni control razonable de datos, el primer paso no es ese. El primer paso es ordenar la base.
Ahí está, en el fondo, la diferencia entre sumar tecnología y construir una capacidad. Si quieres saber cómo aterrizarlo a tu operación de la manera correcta, contáctanos y agenda una reunión sin costo con nuestros expertos.