Escrito por Llevo cerca de dos años y medio trabajando en QA, repartido casi en partes iguales entre pruebas manuales y automatización, y si hay algo que he aprendido en el camino es que probar software no es buscar que las pruebas pasen en verde. Es buscar todas las formas en las que algo puede romperse antes de que lo haga un usuario real. Son dos objetivos que suenan parecidos, pero que en la práctica separan a quien ejecuta casos de prueba de quien realmente asegura calidad.
Al principio, mi trabajo se sentía como seguir una lista: paso uno, paso dos, verificar resultado esperado. Con el tiempo entendí que esa lista es solo el punto de partida. Las fallas que realmente importan casi nunca están en el camino feliz — están en lo que nadie escribió en el caso de prueba: qué pasa si el campo llega vacío, qué pasa si dos personas hacen la misma acción al mismo tiempo, qué pasa si alguien mete una entrada maliciosa donde se esperaba un texto inocente.
Ahí es donde la automatización se vuelve una herramienta poderosa: me permite correr en minutos cientos de casos repetitivos que, hechos a mano, tomarían días y estarían llenos de errores humanos por cansancio. Pero automatizar sin criterio es tan riesgoso como no probar nada: un script que solo confirma que «el botón existe» no está protegiendo a nadie de un bug real.
Si tengo que resumirlo en una idea, es esta: QA no es la última barrera antes de producción, es una forma de pensar que debería estar presente desde que se diseña la funcionalidad, no solo cuando ya está construida.
Cuando entro tarde a un proyecto, cuando la calidad se revisa solo al final, los defectos que encuentro ya no son simples bugs: son decisiones de diseño que hay que revertir, con el costo en tiempo y esfuerzo que eso implica. Cuando entro temprano, cuando puedo cuestionar un requerimiento ambiguo antes de que se convierta en código, ese mismo defecto nunca llega a existir. Por eso creo que el rol de QA gana valor real cuando deja de ser «el que encuentra errores» y se conviere en «el que ayuda a que no existan».
Hace poco vivimos esto de primera mano: un flujo de automatización que normalmente nos habría tomado semanas, incluso meses, construirlo desde cero, lo sacamos en 2-3 días con ayuda de IA. Eso no es una mejora marginal, es un cambio de escala en lo que un equipo de QA puede cubrir en el mismo tiempo.
Pero esa velocidad no elimina el criterio, lo hace más importante. Algo que me sorprendió en ese proceso fue ver a la IA trabajar casi como un compañero durante el recorrido: mientras iba descubriendo y armando el flujo de automatización, ella misma iba avisando errores previsibles, señalando qué era viable hacer y qué no. Eso agiliza muchísimo la construcción, pero la decisión final —si esa advertencia tenía sentido para nuestro caso, si el flujo cubría lo que realmente le importa al negocio, si los casos borde estaban bien pensados— seguía siendo nuestra. La IA nos ayudó a escribir el script más rápido y a anticipar tropiezos, no a decidir qué merecía ser automatizado ni qué validaciones eran realmente críticas. Ese trabajo de definir qué probar y por qué sigue siendo nuestro. Una IA puede darte en horas lo que antes tomaba semanas de código; a nosotros nos toca decidir si eso que generó protege al usuario o solo parece que lo hace.
Cada vez que encuentro un bug antes de que llegue a producción, estoy evitando que un usuario real —alguien que nunca voy a conocer— tenga una mala experiencia, pierda información o, en algunos casos, pierda dinero. Esa es la reflexión que quiero dejar: la calidad de software no es un checklist que se marca al final, es una forma de cuidar a las personas que van a usar lo que construimos, incluso cuando nadie más está mirando ese detalle.
Pasar de semanas a 2-3 días automatizando un flujo con IA es una ventaja enorme, pero solo si detrás de esa velocidad sigue habiendo alguien que entienda qué se está probando y por qué. El criterio para saber qué vale la pena probar sigue siendo la parte que ninguna herramienta puede reemplazar; la IA solo hace que equivocarse o acertar en esa decisión tenga consecuencias mucho más rápidas.
Todavía estoy cursando los últimos semestres de Ingeniería de Software, y quizás por eso valoro tanto este punto: uno podría pensar que, con tantas herramientas resolviendo cosas por nosotros, lo que se estudia en la carrera pierde sentido. Es justo al contrario. Entre más rápido trabaja la IA, más falta hace entender bien los fundamentos para saber si lo que está entregando es correcto.
