Qué tareas puede agilizar la IA y cuáles requieren criterio de QA
Una herramienta de IA puede sugerir pruebas, preparar datos, recorrer una pantalla o resumir resultados. El equipo sigue decidiendo qué riesgos importan, qué resultado demuestra que una función está bien y cuándo hay que investigar o detener una prueba confusa. No hace falta revisar cada clic: sí hace falta comprobar las decisiones que podrían afectar pagos, permisos, información personal o acceso al servicio.
En charlas y eventos de testing se debate cómo repartir estas tareas entre personas y herramientas. Es una conversación sobre una forma de trabajar, no un nuevo cargo con una definición única. Tampoco demuestra que todas las empresas estén cambiando sus puestos al mismo ritmo. Lo concreto es evaluar qué ayuda aporta la IA en cada equipo y quién responde por el resultado.
Aprende a convertir requisitos y riesgos en criterios claros para decidir si el resultado es correcto. Dale a la herramienta la información necesaria para que no invente reglas; comprueba si sus sugerencias son pertinentes, si se pueden repetir y qué alertas son errores reales. Conserva un registro de los pasos y resultados para poder reconstruir lo ocurrido. Según el producto, suma conocimientos de APIs, datos, registro de fallos, seguridad y accesibilidad.
También practica la revisión de código y tests generados: comprobar aserciones débiles, datos frágiles, dependencias ocultas y cobertura que solo aumenta el número de casos. En sistemas generativos, añade evaluación de entradas y salidas, robustez, privacidad y comportamiento ante instrucciones adversas. Las herramientas cambian rápido; el criterio de calidad y el conocimiento del dominio duran más.
Qué puede cambiar de aquí a 2027
La evidencia disponible hasta noviembre de 2026 muestra que los equipos están cambiando algunas tareas, pero no permite afirmar que la IA vaya a reemplazar a quienes trabajan en QA. El World Quality Report dice que 89% de las organizaciones encuestadas estaba probando o usando IA generativa en calidad de software; solo 15% la había extendido a toda la empresa. Probar una herramienta no significa que pueda trabajar sin supervisión ni que ya haya mejorado los resultados.
Para prepararte, anota qué tareas se automatizan, quién revisa los cambios y resultados, qué errores todavía requieren investigación y qué conocimientos faltan en el equipo. En una entrevista, cuenta un caso concreto: qué riesgo detectaste, cómo decidiste qué probar, qué evidencia revisaste y qué mejoró. Eso explica mejor tu experiencia que enumerar herramientas o prompts.
Imagina un cambio en la renovación de una suscripción. Una herramienta puede sugerir pruebas para una cuenta activa, una vencida y otra cuyo pago fue rechazado; también puede preparar datos ficticios y recorrer el flujo. La persona de QA comprueba si falta algún caso importante, confirma qué debe pasar con la factura y el acceso, verifica que no se hayan usado cuentas reales y revisa cualquier fallo. Después de la corrección, se pueden repetir las pruebas afectadas.
Este reparto solo funciona si hay límites claros: un ambiente de prueba aislado, cuentas ficticias, acciones permitidas, un máximo de intentos y una regla para detener la prueba. Sin esos límites, la herramienta podría modificar datos, crear cargos o marcar como error un resultado normal. El trabajo de QA consiste en explicar qué debe comprobarse, fijar esos límites y decidir si los resultados realmente demuestran que la función está bien.
Cómo elegir qué tareas delegar
Antes de delegar una tarea, pregunta: ¿cómo vamos a comprobar la respuesta?, ¿un error se puede revertir?, ¿hay datos sensibles?, ¿la herramienta tiene la información necesaria?, ¿alguien puede revisar el resultado a tiempo? Preparar un borrador o resumir registros sin datos personales suele ser de bajo riesgo. Los cambios que afectan permisos, pagos, información personal o seguridad necesitan más controles y una aprobación humana. En una decisión crítica, se puede automatizar la recopilación de datos y dejar la decisión final en manos del equipo.
El World Quality Report 2025–26 muestra que las empresas valoran tanto los conocimientos de IA generativa (63%) como los fundamentos de calidad (60%) y la comunicación oral y escrita (51%). La lectura práctica no es “aprender prompts y listo”: hace falta combinar conocimientos técnicos, experiencia en testing y capacidad para explicar riesgos. La IA puede ayudar a analizar; el equipo debe poder explicar por qué confía —o no— en el resultado.
En el primer mes, elige un proceso conocido y anota los riesgos, los datos y qué resultado se considera correcto. En el segundo, prueba una tarea concreta —por ejemplo, proponer pruebas a partir de los requisitos— y revisa si las propuestas sirven, repiten casos, omiten situaciones importantes o cuestan demasiado tiempo de revisión. En el tercero, incorpora solo lo que haya dado buen resultado y deja por escrito cómo se detiene, quién aprueba y cómo repetir una prueba que falló. La meta es saber dónde ayuda de verdad, no usar IA en todas partes.
Para una entrevista, lleva una historia completa: riesgo inicial, decisión de cobertura, evidencia encontrada, falso positivo descartado, defecto confirmado y resultado del cambio. Explica qué parte delegaste, qué verificaste y qué no permitiste que hiciera el agente. Esa narrativa demuestra criterio técnico, comunicación y responsabilidad; enumerar proveedores o prompts no lo demuestra por sí solo.
El cambio está en repartir el trabajo, no en renombrar el puesto
La colaboración entre personas y herramientas de IA describe una forma de trabajar, no una categoría profesional normalizada ni una predicción de que todo QA vaya a gestionar agentes. En un equipo, una persona puede usar IA para preparar borradores de casos; en otro, la prioridad será revisar el código generado, definir un oráculo para un servicio conversacional o automatizar una parte repetitiva del análisis. El puesto cambia según el producto, la regulación, el equipo y el costo del error. Las encuestas de adopción muestran experimentación amplia, pero la proporción de organizaciones que llega a escala es bastante menor; adoptar una herramienta no equivale a cambiar toda la estructura laboral.
Para hablar con precisión, separa tareas de responsabilidades. La búsqueda de combinaciones, la preparación inicial de datos o el resumen de logs se pueden asistir. Definir qué significa “correcto”, priorizar riesgos del negocio, aprobar una excepción o decidir si un release sale siguen requiriendo criterio y responsabilidad explícita. Algunas tareas pasarán a desarrollo, producto o plataforma; otras aparecerán alrededor de evaluación y control. No hay evidencia para afirmar que ese reparto será igual en todas las empresas ni para prometer que el número de puestos aumentará o caerá en una proporción concreta.
Clasifica una tarea por cuatro factores: impacto de equivocarse, facilidad de verificar el resultado, reversibilidad y exposición de datos. Generar ideas de casos para un requisito público y revisarlas suele ser de menor riesgo que cambiar permisos o ejecutar pagos. Un agente puede explorar una pantalla en un ambiente ficticio, pero si no distingue una cuenta real, no debería tener acceso a ella. Cuando el resultado se verifica con una aserción independiente y puede revertirse, hay más margen para automatizar; si depende de una interpretación ambigua o afecta a personas, eleva el control y conserva una aprobación humana.
La delegación debe dejar huella: versión de la aplicación, prompt o instrucciones, herramientas disponibles, límites de acciones, datos usados y evidencia devuelta. Esto permite investigar por qué dos ejecuciones dieron respuestas distintas. También evita atribuir a la persona un fallo del agente o aceptar el resumen como si fuera la evidencia original. Una buena operación permite que el sistema diga “no tengo información suficiente”, entregue una falla técnica sin convertirla en defecto de producto y detenga acciones fuera de alcance.
Qué conviene practicar durante los próximos tres meses
En el primer mes, elige un flujo que conozcas y escribe qué requisito cubre cada caso, qué datos utiliza y qué evidencia demuestra el resultado. En el segundo, prueba una tarea de IA con datos ficticios y una muestra pequeña: generar casos, revisar un diff o clasificar fallos. Guarda los resultados rechazados y el tiempo de corrección, no solo los aciertos. En el tercero, compara con el método actual y decide si lo mantienes, lo ajustas o lo descartas. Este plan produce una historia concreta para el equipo y una experiencia defendible para una entrevista, sin depender de predicciones de moda.
Para desarrollar el perfil, combina fundamentos de testing con una especialidad que el producto necesite: API y contratos, automatización, datos, rendimiento, accesibilidad, seguridad o evaluación de sistemas generativos. Aprende a leer trazas, revisar permisos y explicar un riesgo en lenguaje que entienda producto y desarrollo. La habilidad no es escribir prompts bonitos; es diseñar una comprobación repetible, detectar cuándo el modelo inventó una regla y mostrar con evidencia por qué una decisión es confiable. La demanda real de cada competencia debe confirmarse con roles y conversaciones de tu mercado, no inferirse de una charla o un informe global.
Cuando una herramienta genera casos o ejecuta recorridos, el valor de QA puede volverse menos visible si el equipo solo cuenta scripts escritos o pruebas ejecutadas. Conviene explicarlo con resultados observables: qué riesgo se descubrió antes del release, qué supuesto ambiguo se aclaró, qué evidencia permitió descartar un falso positivo y qué decisión cambió gracias a esa revisión. Esto no significa atribuir todo el resultado a QA; significa mostrar la conexión entre el análisis y una decisión de producto o ingeniería. Un caso concreto ayuda a que desarrollo y liderazgo entiendan por qué la revisión experta sigue teniendo un lugar en el flujo.
También cambia la forma de aprender. No hace falta dominar cada proveedor nuevo que aparece. Es más útil aprender a comprobar salidas, medir errores de clasificación, leer logs y reconocer cuándo una prueba no cubre el requisito que dice cubrir. Para alguien que empieza en QA, una base en técnicas de prueba, SQL, HTTP, control de versiones y lectura de errores da más opciones que memorizar una interfaz específica. Para alguien con experiencia, el paso siguiente puede ser revisar cómo se integran agentes con permisos, datos y evidencias. En ambos casos, el criterio se demuestra con trabajo reproducible y decisiones explicadas, no con un título de moda.