Todo lo que escribo está basado en tres pilares: técnicas de testing que vale la pena conocer, inteligencia artificial aplicada al día a día del QA, y lo que aprendí liderando calidad en equipos reales. No son categorías arbitrarias — son los tres problemas que más se repiten en mi carrera.
Serie especial — una curiosidad por día, del 13 al 19 de abril
Instalas Playwright, corres el ejemplo de fábrica y en veinte minutos tienes un test en verde. Y después te quedas parada. Ese primer verde no es tu framework: son dos piezas de seis, funcionando solas. Acá va el orden en que aparecen las otras cuatro —no el orden de la lista, sino el que te impone el dolor— con el código de cada una y la señal que te avisa que llegó su turno.
Playwright trae tres agentes de IA que exploran tu aplicación, escriben los tests y reparan los que fallan. Los instalé, los corrí y los enseñé en vivo. Automatizan cinco de las seis piezas de un framework, y hacen bien su trabajo. Pero hay dos frases en la documentación oficial que cambian cómo tienes que usarlos: el generator valida sus propias assertions contra la aplicación, y el healer repara los tests hasta que pasen. Ninguna de las dos es un bug — son el diseño. Y las dos apuntan al mismo lugar: el criterio sigue siendo tuyo.
Heredé una suite con doscientos casos en verde que no probaba nada: los valores esperados se habían sacado de correr el sistema. Todo eso pasó por no responder una pregunta de una línea —de dónde sale el valor esperado—, que es la pregunta más vieja del testing y la que el mundo de la IA está redescubriendo ahora. Acá van las cinco fuentes posibles, cómo asertar cuando el resultado cambia cada vez (incluso si lo escribió un modelo) y cuatro preguntas para que tus goals fallen por la razón correcta.
En la parada anterior viste tu framework a vuelo de pájaro: cuatro funciones que toda herramienta resuelve. Ahora bajamos a tierra y lo desarmamos entero. Seis piezas, mapeadas en Playwright, k6 y Appium, para que veas que son las mismas en UI, performance y mobile — y una checklist para evaluar cualquier framework, el tuyo o el que heredaste.
Cuando te dicen 'arma un framework de automatización desde cero', la parálisis no viene de que te falte habilidad. Viene de que nadie te dio el nombre ni el mapa de lo que estás construyendo. Esa cosa tiene nombre: harness. Y cuando la nombras, aparece el orden.
El mundo dev y de IA habla de loops, goals y harnesses como si los hubiera inventado. No es así: son conceptos de testing con décadas encima. Acá te los devuelvo traducidos a tu trabajo, y te muestro por qué te ponen a ti —no a la IA— en el centro.
No tienes flaky tests. Tienes tests mal arquitectados. Las 5 causas reales con código Playwright, el protocolo para cuando bloquean tu deploy, y la línea entre decisión de ingeniería y deuda invisible.
La pantalla negra con letras verdes que te hace sentir que no perteneces. Pero el terminal no es para hackers ni para programadores: es solo otra forma de hablarle a tu computadora. Y es exactamente donde viven las herramientas de IA que de verdad te van a cambiar el trabajo. Aquí te lo explico sin asumir que programas.
ChatGPT, Claude o Gemini. La pregunta que más me hacen, y la que peor se responde — con benchmarks que a un QA no le sirven de nada. Aquí va mi comparación desde el trabajo real: analizar historias, generar casos, escribir tests. Cuál uso yo, por qué, y dónde me falla.
Si sientes que llegaste tarde a la IA en QA, no es verdad. No te falta información — te sobra. Lo que te falta es un mapa y un orden. Aquí tienes los dos: qué aprender primero, qué ignorar por ahora, y la ruta exacta para avanzar sin perderte.
Todos buscan el agente más capaz. Pero el salto no es de inteligencia: es de perspectiva. Un equipo de agentes con miradas distintas cubre lo que uno solo no alcanza — y tú eres quien lo dirige.
En la Parte 1 cubrimos al dev y al PO. Hoy vienen los dos roles donde el cambio queda invisible durante meses: el arquitecto y el Scrum Master. Por qué el pipeline de agentes ES una decisión arquitectónica nueva, por qué la velocity te miente con SDD, y las tres ceremonias del sprint que se transforman — más la única que sigue igual.
Spec-Driven Development acaba de promover al QA sin que nadie te avise. Si el dev escribe la spec y la IA genera código y tests, validar después es llegar tarde. Esta es la primera parte: tu nuevo trabajo frente al dev y al product owner cuando el ciclo entero se movió tres pasos antes.
Un usuario reportó que no le llegaba el SMS para recuperar contraseña. Mi monitoreo no lo detectó. Mi suite de tests tampoco. Le pasé el bug a Claude Code con acceso al portal de pruebas y le pedí que investigara qué más podía estar fallando ahí. Lo que salió de esa conversación me cambió cómo arranco a testear un flujo nuevo — y no es lo que la mayoría de hilos sobre IA para QA están contando.
Si SDD es la práctica, Spec Kit es la herramienta más estándar para implementarla. Antes de instalarla, conviene saber qué es realmente — y qué no es.
El 70% del tráfico web es mobile. Pero el 80% de las suites automatizadas que veo son desktop-only. ¿Qué pasa con el resto? Lo evitamos. Y en 2026 ya no hay excusa.
Spec-Driven Development es lo más mencionado en tecnología desde hace meses. La explicación que circula es siempre la del dev. La pregunta que nadie responde: si la IA escribe los tests desde la spec, ¿para qué pagan a los QA? Acá la respuesta sin esquivar.
Un software crítico en aviación cuesta entre 10 y 30 veces más desarrollarlo que software comercial. La mayor parte de ese costo es testing. ¿Qué podemos aprender de la industria donde un bug puede costar vidas?
Minecraft, GTA V, Skyrim — todos los videojuegos más exitosos de la historia salieron con bugs conocidos. Miles de ellos. Y aún así fueron éxitos. ¿Qué dice eso sobre cuándo un producto está 'listo'?
Existe una técnica de testing que no requiere abrir un navegador, escribir código, ni configurar ambientes. Encuentra bugs reales. Y la mayoría de QAs la ignora porque parece demasiado simple. Se llama rubber duck testing.
Según múltiples estudios de la industria, entre el 30% y el 50% de los defectos en producción son detectados por usuarios finales — no por el equipo de QA. ¿Qué dice eso sobre cómo probamos?
Netflix tiene un ejército de herramientas cuyo único trabajo es destruir partes de su infraestructura en producción. No es un accidente. Es una estrategia. Se llama Chaos Engineering y es la razón por la que Netflix casi nunca se cae.
Cuando Tesla envía una actualización OTA, 2 millones de vehículos la reciben casi al mismo tiempo. No hay rollback físico. No hay 'ctrl+z'. ¿Cómo se testea algo así?
En 2023, Google pagó más de 12 millones de dólares a personas que encontraron bugs en sus productos. No hackers. No ataques. Profesionales del bug hunting. ¿Qué nos enseña esto sobre testing?
Acabas de leer las 3 guías de la trilogía. Sabes elegir herramienta, montar arquitectura y posicionarte. Y aún así nadie te respondió la pregunta incómoda: ¿tienes que hacerlo?
Pasé de pedirle cosas a la IA a que trabaje conmigo. Con roles definidos, contexto compartido, y tareas que se ejecutan sin copiar y pegar. Esta es la historia de cómo lo hice.
6 problemas en una sola historia de usuario. Esto no es una crítica al equipo — es lo que pasa cuando QA no tiene voz en el refinamiento.
Uso IA en mi flujo de trabajo diario como QA. No como experimento — como herramienta real. Después de meses de uso honesto, tengo una lista muy clara de dónde me supera y dónde falla horrible.
Tenía 44 tests E2E y pensaba que estaba cubierta. Luego descubrí mutation testing, me di cuenta de que no podía usarlo con Playwright, escribí 92 unit tests desde cero, y encontré 3 bugs reales que pasaron code review.
200 tests automatizados. Dashboard en verde. Y nadie sabe qué validan. Por qué el coverage no es confianza — y qué medir en su lugar.