“Ya terminaron de desarrollar. Ahora pasemos a QA.”

Pero… ¿realmente debería funcionar así?

Si venimos siguiendo esta serie sobre ISTQB Foundation Level, hasta ahora hablamos de qué es el testing, por qué es necesario, sus principios, las actividades, el testware, los roles y las habilidades necesarias para trabajar en testing.

Ahora damos un paso más.

Entramos en el Capítulo 2: Testing Throughout the Software Development Lifecycle y comenzamos por un concepto fundamental:

el testing debe adaptarse al ciclo de vida del desarrollo de software.

¿Qué es un SDLC?

SDLC significa Software Development Life Cycle, o ciclo de vida del desarrollo de software.

Es una representación de cómo se organizan y relacionan las diferentes actividades necesarias para construir un producto de software.

Existen diferentes modelos de SDLC.

Entre ellos encontramos:

• Modelos secuenciales, como Waterfall o V-Model.

• Modelos iterativos.

• Modelos incrementales.

• Enfoques y prácticas Agile.

Y esto es importante porque la forma en que desarrollamos software influye directamente en cómo hacemos testing.

¿Testing al final o testing durante todo el proceso?

Esta es una de las ideas que más me interesa destacar.

Si trabajamos con un modelo secuencial, algunas actividades de testing pueden concentrarse más adelante en el proceso.

Pero eso no significa que el tester deba esperar hasta que exista código ejecutable para comenzar a trabajar.

Podemos participar mucho antes.

Por ejemplo:

• Revisando requisitos.

• Analizando historias de usuario.

• Identificando riesgos.

• Diseñando condiciones de prueba.

• Participando en revisiones.

Esto nos lleva a una idea que seguramente ya escuchaste:

“Shift Left”

La idea de shift left consiste, de manera general, en llevar las actividades de testing hacia etapas más tempranas del desarrollo.

¿Por qué?

Porque encontrar un problema temprano suele ser mucho más conveniente que descubrirlo cuando el producto está a punto de salir a producción.

No existe un único modelo de desarrollo

Una de las cosas que destaca ISTQB es que el testing debe adaptarse al contexto.

No podemos aplicar exactamente la misma estrategia a todos los proyectos.

Imaginemos dos situaciones.

Proyecto A

Una aplicación bancaria con requisitos muy definidos, fuertes regulaciones y procesos formales.

Probablemente necesitemos:

• Mucha documentación.

• Trazabilidad.

• Revisiones formales.

• Evidencias de prueba.

• Controles específicos.

Proyecto B

Una aplicación web que evoluciona rápidamente y recibe cambios todas las semanas.

En este contexto probablemente tengamos:

• Iteraciones cortas.

• Feedback frecuente.

• Automatización.

• Pruebas de regresión.

• Documentación más liviana.

El testing sigue siendo necesario en ambos casos.

Pero la estrategia puede ser muy diferente.

¿Qué cambia según el SDLC?

El modelo de desarrollo elegido puede afectar diferentes aspectos del testing.

Según ISTQB, entre ellos encontramos:

📌 El alcance y momento de las actividades de prueba

¿Cuándo probamos?

¿Qué niveles y tipos de prueba necesitamos?

📌 La documentación

¿Cuánto necesitamos documentar?

¿Necesitamos documentos formales o podemos utilizar artefactos más livianos?

📌 Las técnicas de prueba

Las técnicas utilizadas también pueden variar según el contexto.

📌 La automatización

En entornos donde tenemos entregas frecuentes, la automatización puede resultar especialmente importante para facilitar las pruebas de regresión.

📌 El rol del tester

Y algo que me parece especialmente interesante:

el rol y las responsabilidades del tester también pueden cambiar.

El tester no trabaja de la misma manera en todos los equipos.

¿Y qué pasa en Agile?

Cuando hablamos de Agile, muchas veces aparece la idea de que:

“Como trabajamos con Scrum, hacemos testing al final del sprint.”

Pero eso contradice bastante la idea de un enfoque colaborativo.

En un entorno Agile, el testing debería integrarse dentro de la iteración.

Los testers pueden participar desde el refinamiento de historias y colaborar con desarrolladores y otros miembros del equipo para detectar problemas lo antes posible.

Además, las entregas frecuentes generan una necesidad importante:

regresión.

Si cada iteración incorpora nuevos cambios, necesitamos asegurarnos de que esos cambios no rompan funcionalidades existentes.

Por eso la automatización puede adquirir un papel muy importante.

Una práctica importante: para cada actividad de desarrollo, una actividad de testing

Este es uno de los conceptos del syllabus que más me gusta porque cambia nuestra forma de pensar el testing.

No deberíamos imaginar algo así:

Desarrollo → Desarrollo → Desarrollo → Testing

Sino algo más parecido a:

Desarrollo ↔ Testing

Cada actividad de desarrollo debería tener su correspondiente actividad de calidad.

Por ejemplo:

Requisitos → revisión de requisitos

Diseño → revisión del diseño

Implementación → pruebas de código y pruebas dinámicas

Integración → pruebas de integración

De esta manera, el testing deja de ser una etapa que aparece al final y pasa a formar parte del proceso completo.

¿Qué podemos aprender como testers?

Creo que uno de los aprendizajes más importantes de este capítulo es que no existe una receta universal para hacer testing.

El contexto importa.

No es lo mismo probar:

• una aplicación bancaria,

• un videojuego,

• una aplicación médica,

• una tienda online,

• un sistema interno de una empresa.

Tampoco es lo mismo trabajar en Waterfall, en un entorno Agile o en un equipo que realiza entregas continuas.

Por eso un buen tester necesita entender no solamente qué probar, sino también:

¿En qué contexto estoy trabajando y cuál es la mejor estrategia para este producto?

Testing no es una etapa

Si tuviera que resumir todo este artículo en una sola idea, sería esta:

El testing no debería ser una etapa aislada del desarrollo.

Debe integrarse con las actividades de desarrollo y adaptarse al contexto del proyecto.

Y esto también cambia nuestra forma de entender el rol del tester.

No estamos esperando al final para encontrar errores.

Estamos participando durante todo el proceso para aportar información sobre la calidad y ayudar a reducir riesgos.

Para reflexionar

Te dejo una pregunta para cerrar:

En el proyecto en el que estás trabajando actualmente, ¿el testing está integrado durante todo el desarrollo o todavía aparece principalmente al final?

Me interesa mucho conocer diferentes experiencias, porque probablemente la respuesta sea muy distinta dependiendo del equipo y del producto.

Nos seguimos leyendo en la próxima entrega de esta serie sobre ISTQB Foundation Level.

Si te interesan estos temas, suscríbete!

Suscríbete ahora

Para seguir estudiando

Este artículo está basado en el apartado 2.1 – Testing in the Context of a Software Development Lifecycle del ISTQB Certified Tester Foundation Level v4.0.1. El syllabus oficial incluye modelos secuenciales, iterativos e incrementales, además de prácticas Agile, y explica cómo la elección del SDLC afecta el alcance, momento, documentación, técnicas, automatización y responsabilidades del testing.

Consultar el syllabus oficial ISTQB CTFL v4.0.1

Primera impresión: ¿qué es Tomation?

Tomation se presenta como un framework de automatización de pruebas de UI basado en TypeScript, pero con una particularidad interesante: separa la definición de los elementos y la lógica de las pruebas de la ejecución.

La idea general es:

TypeScript → DSL → compilación → .tomation.json → extensión del navegador → ejecución

El proyecto utiliza una DSL declarativa para que los tests puedan escribirse de una manera relativamente cercana al lenguaje natural. Por ejemplo:

Test('Login with valid credentials', () => {
  Login.fillCredentials({
    username: 'admin',
    password: 'secret'
  })

  Login.submit()

  AssertHasText(
    Login.message,
    'Login successful'
  )
})

Esto me parece uno de los puntos más interesantes para analizar: ¿hasta qué punto una DSL puede hacer que los tests sean más legibles y mantenibles?

Lo que hace diferente a Tomation

1. TypeScript como lenguaje de definición

Los tests se escriben en TypeScript y utilizan paquetes como:

@tomationjs/compiler
@tomationjs/dsl

El compilador transforma el código en un archivo .tomation.json, que posteriormente consume la extensión del navegador.

Esto crea una arquitectura bastante diferente de un framework tradicional.

2. Page Object Model integrado

El repositorio utiliza POM para definir los elementos:

const usernameInput =
  is.INPUT
    .where(idIs('username'))
    .as('Username')

Y después el test trabaja con ese objeto en lugar de preocuparse directamente por el selector.

Además, Tomation ofrece diferentes matchers:

• idIs

• innerTextIs

• classIncludes

• placeholderIs

• nameIs

• typeIs

• ariaLabel

• roleIs

• dataAttr

• etc.

También permite childOf(), navegación relativa del DOM y XPath.

3. Tasks reutilizables

Otra característica que merece atención son las Tasks.

Por ejemplo:

const fillCredentials = Task((params) => {
  const { username, password } = params

  Type(username).in(usernameInput)
  TypePassword(password).in(passwordInput)
}).as('Fill Credentials')

Después:

Login.fillCredentials({
  username: 'admin',
  password: 'secret'
})

La idea es encapsular acciones complejas y reutilizarlas en distintos tests.

Para alguien que trabaja en automatización, esto es interesante porque ataca uno de los problemas clásicos: tests que terminan llenos de pasos repetidos.

4. Algo que me parece especialmente interesante: Automations

Aquí creo que hay una característica que podría convertirse en uno de los puntos fuertes de tu artículo.

Tomation distingue entre:

Los tests tienen los valores definidos en el código.

Las automations reciben parámetros en tiempo de ejecución mediante un formulario de la extensión.

Por ejemplo:

Automation(
  'Create Account',
  (params: {
    email: string
    environment?: string
  }) => {

    // pasos de la automatización
  }
)

La extensión puede generar los campos correspondientes para que el usuario introduzca los valores.

Incluso soporta:

role: 'admin' | 'user' | 'viewer'

que se convierte en un selector.

Esto abre una posibilidad interesante:

Tomation no solamente puede utilizarse para regression testing, sino también para crear procedimientos automatizados que una persona pueda ejecutar manualmente proporcionando determinados parámetros.

5. Contexto y datos dinámicos

También permite guardar valores obtenidos durante la ejecución.

Por ejemplo:

SaveText(confirmationCode).as('code')

y posteriormente:

Type('{{ctx.code}}').in(verificationInput)

Esto permite construir flujos donde un dato generado en un paso se utiliza posteriormente.

Para automatización de aplicaciones con datos variables, esto puede ser bastante útil.

Demo

Facundo nos muestra cómo usar el framework y cómo instalarlo en local:

Conclusión

Probar una herramienta nueva de automatización siempre implica un poco de curiosidad y otro poco de escepticismo. Y creo que esa es precisamente la mejor manera de acercarse a Tomation.

En esta primera experiencia encontré una propuesta interesante: una herramienta que intenta simplificar la automatización de pruebas mediante TypeScript, una DSL orientada al testing, Page Object Model y componentes reutilizables como las Tasks. La posibilidad de trabajar también con Automations abre, además, una perspectiva diferente a la de un framework pensado exclusivamente para ejecutar suites de regresión.

Pero Tomation todavía tiene camino por recorrer. Al ser un proyecto relativamente reciente, todavía quedan muchas preguntas por responder antes de pensar en utilizarlo como herramienta principal en un proyecto de automatización grande: estabilidad, funcionalidades disponibles, debugging, reporting, integración con CI/CD y, sobre todo, cómo se comporta cuando los escenarios se vuelven realmente complejos.

Y quizás ese sea precisamente su atractivo.

Creo que es mucho más interesante preguntarnos qué problemas intenta resolver, qué tan bien lo hace y cómo evolucionará el proyecto.

Mi experiencia hasta ahora me deja con ganas de seguir explorándolo. Y, para una herramienta nueva, eso ya es una buena señal.

Tomation todavía está dando sus primeros pasos, pero definitivamente es un proyecto al que vale la pena seguirle la pista.

Si te interesa probar esta herramienta open source, te dejo el repositorio aquí.

Si te gustaría compartir alguna solución para testing con la comunidad, no dudes en contactarme!

Suscríbete ahora

Entre conceptos técnicos, estrategias de prueba y procesos, aparece un capítulo dedicado a algo completamente diferente:

La psicología del testing.

Al principio me pregunté qué tenía que ver la psicología con encontrar defectos.

Con el tiempo entendí que tiene muchísimo que ver.

Porque nuestro trabajo no consiste solamente en probar software.

Trabajamos con personas.

Y muchas veces, la forma en que nos comunicamos tiene tanto impacto como la calidad de nuestras pruebas.

Me gustaría hacerte una pregunta.

👉 ¿Qué habilidad consideras más importante para un tester además de los conocimientos técnicos?

¿La comunicación?

¿El pensamiento crítico?

¿La curiosidad?

¿La empatía?

Puedes dejarme tu opinión en los comentarios 😉

¿La razón? Porque el testing no solo consiste en encontrar defectos. También implica trabajar con personas.

Y muchas veces, esa es la parte más difícil.

Encontrar defectos no significa buscar culpables

Imaginemos esta situación.

Después de varios días de trabajo, un desarrollador termina una nueva funcionalidad. El equipo está conforme y llega el momento de probarla.

Durante las pruebas encontramos varios defectos.

¿Cómo comunicamos ese resultado?

Si decimos:

“Tu código tiene muchos errores.”

Es probable que la otra persona se sienta atacada.

En cambio, si decimos:

“Durante las pruebas encontramos algunos comportamientos que no coinciden con lo esperado. Revisémoslos juntos.”

La conversación cambia completamente.

El objetivo del testing nunca es demostrar que alguien hizo mal su trabajo.

Nuestro objetivo es ayudar a mejorar la calidad del producto.

El producto es el que tiene defectos, no las personas

Este es uno de los cambios de mentalidad más importantes.

Los defectos aparecen por muchas razones:

• Requisitos poco claros.

• Cambios de último momento.

• Restricciones de tiempo.

• Complejidad técnica.

• Errores humanos, que son completamente normales.

En la mayoría de los casos no existe un único responsable.

La calidad es una responsabilidad compartida por todo el equipo.

La importancia de la comunicación

Gran parte del trabajo de un tester consiste en comunicar.

Comunicar qué se probó.

Comunicar qué riesgos encontramos.

Comunicar cómo reproducir un defecto.

Comunicar el impacto que puede tener un problema para el usuario.

Un reporte técnicamente correcto puede perder efectividad si está escrito de forma poco clara o genera confrontación.

Por eso, una buena comunicación es tan importante como una buena técnica de testing.

La independencia del tester

Otro concepto interesante que introduce ISTQB es el de la independencia de las pruebas.

¿Por qué muchas organizaciones prefieren que otra persona pruebe el software?

Porque todos tenemos sesgos.

Quien desarrolla una funcionalidad conoce tan bien su solución que, muchas veces, inconscientemente evita pensar en escenarios alternativos.

Un tester aporta una mirada diferente.

Hace preguntas distintas.

Explora caminos que quizá nadie había considerado.

Eso no significa que un desarrollador no pueda probar su propio código.

De hecho, debería hacerlo.

Pero incorporar una mirada independiente suele aumentar las probabilidades de encontrar defectos.

Independencia no significa trabajar separados

A veces se interpreta la independencia como una separación entre desarrollo y testing.

Hoy sabemos que ocurre exactamente lo contrario.

Los equipos más efectivos colaboran desde el inicio.

Los testers participan en el análisis de requisitos.

Los desarrolladores revisan casos de prueba.

Todos comparten el mismo objetivo: entregar un producto de calidad.

La independencia aporta una perspectiva diferente, pero la colaboración sigue siendo esencial.

¿Qué hace realmente un buen tester?

Con el tiempo descubrí que un buen tester no es quien encuentra más defectos.

Es quien ayuda al equipo a construir un mejor producto.

Eso implica:

• Pensar de forma crítica.

• Hacer buenas preguntas.

• Comunicar con respeto.

• Colaborar con el resto del equipo.

• Mantener siempre el foco en el usuario.

Las habilidades técnicas son fundamentales.

Pero las habilidades interpersonales marcan una enorme diferencia en el impacto que puede tener un profesional de testing.

Reflexión final

Uno de los aprendizajes más valiosos de ISTQB es que el testing no trata solamente de herramientas o metodologías.

También trata de personas.

Cada defecto que reportamos es una oportunidad para mejorar el producto, aprender como equipo y fortalecer la colaboración.

Y quizás esa sea una de las lecciones más importantes para cualquier tester, independientemente de su experiencia.

¿Y tú qué opinas?

¿Crees que la comunicación y la colaboración son tan importantes como las habilidades técnicas en testing?

Me encantaría conocer tu experiencia en los comentarios.

Suscríbete para recibir todas las novedades en tu bandeja de entrada!

Suscríbete ahora

Lo que más me llamó la atención fue que, en lugar de depender de un único agente que haga todo, el proceso se divide entre varios agentes con responsabilidades bien definidas.

El flujo funciona aproximadamente así:

1. El usuario ingresa el requerimiento

El punto de partida es un requisito (por ejemplo, una User Story o un requisito IEEE). Un agente orquestador recibe la información y coordina todo el proceso.

2. Un agente analiza el requisito

El siguiente agente interpreta el requerimiento y genera:

• Criterios de aceptación.

• Validaciones necesarias.

• Requisitos no funcionales (NFRs).

• Reglas de negocio que pueden haberse omitido.

Este paso ayuda a detectar inconsistencias desde el inicio.

3. Otro agente evalúa riesgos

Con la información anterior, un segundo agente especializado:

• Construye una matriz de riesgos.

• Identifica qué funcionalidades tienen mayor impacto.

• Sugiere una estrategia de QA basada en esos riesgos.

De esta manera, el esfuerzo de testing se concentra donde realmente aporta más valor.

4. El orquestador valida los resultados

El agente principal recopila toda la información generada.

Si detecta información incompleta o inconsistente, vuelve a solicitar contexto a los agentes especializados, creando un ciclo de validación hasta obtener un resultado suficientemente confiable.

5. Se generan los entregables

Finalmente, el sistema produce documentación lista para utilizar, como por ejemplo:

• Un reporte en Markdown.

• Un archivo JSON con toda la información estructurada.

Esto facilita integrar el resultado con otras herramientas o pipelines.

Lo que me pareció más interesante

Más que “hacer testing con IA”, este enfoque utiliza la IA para automatizar las tareas de análisis que suelen consumir mucho tiempo.

El tester sigue siendo quien toma las decisiones importantes, pero cuenta con asistentes especializados que ayudan a:

• comprender mejor los requisitos;

• detectar riesgos antes de empezar a probar;

• generar documentación consistente;

• reducir el trabajo repetitivo;

• mantener un proceso más estructurado.

En otras palabras, la IA no reemplaza la experiencia del profesional de QA, sino que actúa como un equipo de asistentes que permite dedicar más tiempo al análisis crítico y menos a las tareas mecánicas.

Te dejo el video con la demo de Leticia a continuación:

Creo que este tipo de arquitectura de agentes es una muestra de hacia dónde está evolucionando el trabajo en QA: no se trata solo de usar ChatGPT para escribir casos de prueba, sino de diseñar flujos donde distintos agentes colaboran entre sí y con el tester para mejorar la calidad del proceso de principio a fin.

¿Qué opinas sobre esta estructura de agentes? Te leo en comentarios 😉

Si tienes un proyecto similar para compartir con la comunidad o conoces a alguien que lo tenga, dejame un mensaje y lo vemos!

Si te interesan estos temas, suscríbete para no perderte de nada!

Suscríbete ahora

Termina el ciclo de pruebas.

Los casos de prueba pasan.

El equipo aprueba el despliegue.

La funcionalidad llega a producción.

Y pocas horas después aparece un mensaje que nadie quiere recibir:

“Encontramos un error en producción.”

La pregunta es inevitable:

¿Cómo pudo pasar?

¿Falló el testing?

¿No probamos lo suficiente?

¿O simplemente es imposible encontrar todos los defectos?

Hoy quiero compartir algunas reflexiones sobre este tema y relacionarlo con uno de los principios más importantes de ISTQB.

Suscríbete ahora

Uno de los conceptos fundamentales que presenta ISTQB Foundation Level es precisamente el proceso de testing, una estructura que nos ayuda a planificar, organizar y controlar las actividades de prueba para que aporten valor al proyecto.

Pero ¿por qué necesitamos un proceso? 🤔

Te lo cuento en el siguiente video…

Si te interesan estos temas, suscríbete para recibir todas las novedades en tu bandeja de entrada 😉

Suscríbete ahora

Aunque es una de las áreas más importantes dentro del desarrollo de software, muchas veces se comunica de forma extremadamente técnica, abstracta o incluso poco visual. Documentación, frameworks, pipelines, reportes, scripts. Mucha teoría y poca demostración real del impacto.

Y justamente por eso me llamó tanto la atención el enfoque de Douglas.

En lugar de explicar conceptos de testing de manera tradicional, gran parte de su contenido muestra herramientas funcionando, automatizaciones reales y flujos visuales que permiten entender rápidamente qué problema resuelven y por qué son útiles.

Eso cambia completamente la experiencia.

En sus propias palabras dijo: “La verdad quiero que la comunidad de QA aproveche estas herramientas que hoy en día nos ayudan a todos a trabajar de forma mas ágil y profesional”.

Mostrar herramientas reales genera otro nivel de aprendizaje

Algo que noto cada vez más en el mundo IT es que las demos reales enseñan mucho más rápido que los tutoriales excesivamente teóricos.

Cuando vemos:

• una herramienta ejecutándose,

• un agente resolviendo tareas,

• una automatización funcionando,

• o un flujo completo de testing,

el aprendizaje se vuelve tangible.

No tenemos que imaginar cómo podría verse en la práctica. Ya lo estamos viendo.

Y eso es justamente lo interesante de muchos de los proyectos compartidos por Douglas: convierten procesos complejos en algo visualmente entendible.

Especialmente en QA y automatización, donde muchas veces el valor del trabajo ocurre “detrás de escena”.

El testing moderno ya no es solamente testing

Otra cosa que me resultó interesante es cómo varios de sus proyectos mezclan:

• automatización,

• inteligencia artificial,

• productividad,

• workflows,

• agentes,

• y experiencia de desarrollador.

Creo que esto refleja bastante bien hacia dónde está evolucionando el QA moderno.

Durante muchos años, el testing estaba asociado principalmente a:

• ejecutar casos de prueba,

• validar funcionalidades,

• encontrar bugs.

Pero hoy el rol está cambiando.

Cada vez más testers trabajan creando:

• herramientas internas,

• sistemas de automatización,

• asistentes inteligentes,

• pipelines,

• soluciones que aceleran procesos completos.

Y ahí aparece una idea que me parece importante:

El futuro del testing probablemente no sea reemplazar testers, sino potenciar testers que sepan trabajar con herramientas inteligentes.

El valor de construir en público

También hay algo muy potente en mostrar proyectos reales públicamente.

En tecnología solemos consumir muchísimo contenido educativo, pero muchas veces queda en:

• teoría,

• explicaciones genéricas,

• o tutoriales básicos.

Mostrar herramientas propias funcionando transmite otra cosa.

Demuestra:

• capacidad práctica,

• resolución de problemas reales,

• creatividad técnica,

• y forma de pensar.

Además, inspira.

Porque ver a otras personas creando herramientas hace que uno también empiece a pensar:
“¿Qué podría construir yo para resolver problemas que veo todos los días?”

El testing también necesita storytelling

Y quizás esta sea la parte más interesante de todas.

Muchas veces creemos que el storytelling pertenece solamente al marketing o al diseño. Pero en realidad también existe storytelling técnico.

La forma en la que mostramos:

• una automatización,

• una herramienta,

• un flujo,

• una demo,

• o incluso un bug,

puede hacer que algo extremadamente técnico se vuelva interesante y fácil de entender.

Y creo que ahí hay una gran oportunidad para quienes trabajamos en QA.

Porque el testing no tiene por qué verse aburrido.

Cuando se comunica bien, puede mostrar:

• ingeniería,

• creatividad,

• estrategia,

• análisis,

• productividad,

• y hasta diseño de experiencia.

De escribir prompts a construir un ecosistema para QA

Uno de los proyectos que más me llamó la atención fue Test Automation AI Agents & Skills, una librería diseñada específicamente para QA Automation Engineers. Su objetivo no es generar casos de prueba de forma mágica, sino proporcionar agentes, instrucciones y habilidades reutilizables que permitan a asistentes de IA trabajar de forma más efectiva dentro de proyectos reales de testing.

Lo interesante es que no se trata de una herramienta ligada a una plataforma específica. El proyecto fue diseñado para funcionar con distintos asistentes como GitHub Copilot, Claude, Cursor o Windsurf, permitiendo reutilizar los mismos conocimientos y flujos de trabajo independientemente de la herramienta elegida.

La estructura del repositorio está organizada alrededor de tres conceptos:

• Agents: especialistas para tareas concretas como generación de pruebas, investigación de tests inestables o planificación de estrategias de testing.

• Instructions: reglas y estándares para mantener consistencia técnica.

• Skills: playbooks reutilizables para tareas frecuentes como testing E2E, accesibilidad, APIs o planificación de pruebas.

Lo que más me hizo reflexionar no fue la tecnología en sí, sino el enfoque.

Durante mucho tiempo, cuando hablábamos de automatización, pensábamos principalmente en frameworks, scripts y pipelines. Ahora empieza a aparecer una nueva capa: sistemas que ayudan a los ingenieros de QA a tomar decisiones, organizar conocimiento y ejecutar tareas complejas con asistencia de IA.

En lugar de preguntarle a un asistente genérico:

“Genera una prueba para esta funcionalidad”

la idea es proporcionarle contexto, reglas, estándares y especializaciones previamente definidas.

Es un cambio de paradigma importante.

No estamos simplemente automatizando pruebas.

Estamos empezando a automatizar partes del conocimiento y de los procesos que utilizan los equipos de QA todos los días.

Reflexión final

Después de recorrer varios de estos proyectos, me quedó una sensación clara:

El QA moderno se está pareciendo cada vez más a ingeniería de productividad.

No se trata solamente de encontrar errores.
Se trata de construir sistemas que ayuden a desarrollar software mejor, más rápido y con menos fricción.

Y quizás una de las habilidades más importantes en los próximos años no sea solamente saber testear…

sino también saber mostrar lo que construimos.

Si estás usando o construyendo este tipo de herramientas para tu trabajo diario en testing y te interesa compartir tu experiencia con la comunidad, escribime!

Puedes acceder a los proyectos de Douglas aquí.

Si te interesan estos temas, suscribite para recibir cada publicación en tu bandeja de entrada!

Suscríbete ahora

👉 el uso de inteligencia artificial en automatización.

Más específicamente:

¿La IA realmente puede ayudarnos a escribir mejores tests?

¿O estamos entrando en una etapa de mucho entusiasmo… pero pocas soluciones reales?

Te leo en comentarios!

👉 Los principios del testing.

Y aunque al principio parecen “teoría para memorizar”, en realidad explican algo mucho más importante:

💡 cómo funciona el testing en la vida real.

🧠 ¿Qué son los principios del testing?

Son ideas fundamentales que surgieron a partir de años de experiencia en proyectos reales.

En otras palabras:

👉 son patrones que se repiten una y otra vez cuando trabajamos con software.

Conocerlos no solo ayuda para aprobar el examen, sino también para pensar como tester.

1️⃣ Las pruebas muestran la presencia de defectos, no su ausencia

El testing puede demostrar que existen bugs.

Pero nunca puede demostrar que el software está 100% libre de errores.

💡 Siempre existe la posibilidad de que haya defectos que no fueron encontrados.

Por eso:

• probar mucho no garantiza perfección

• probar poco aumenta el riesgo

👉 El objetivo real es reducir riesgos.

2️⃣ Las pruebas exhaustivas son imposibles

No podemos probar absolutamente todo.

Imaginate una app con:

• distintos usuarios

• navegadores

• dispositivos

• combinaciones de datos

• idiomas

• permisos

La cantidad de pruebas posibles sería infinita.

Por eso el testing se basa en:

• priorizar

• analizar riesgos

• elegir qué probar primero

💡 Un buen tester sabe qué NO probar también.

3️⃣ Probar temprano ahorra tiempo y dinero

Cuanto antes se detecta un problema:

✔️ más barato es arreglarlo
✔️ menos impacto genera
✔️ menos retrabajo produce

Encontrar un error en un requisito es muchísimo más simple que descubrirlo cuando el sistema ya está en producción.

👉 Por eso hoy se habla tanto de “shift left testing”.

4️⃣ Los defectos tienden a agruparse

La mayoría de los bugs suelen aparecer en pocas áreas del sistema.

💡 Algunas partes del software son naturalmente más problemáticas.

Por ejemplo:

• módulos complejos

• funcionalidades nuevas

• código modificado muchas veces

• integraciones externas

Esto se relaciona con el principio de Pareto:

👉 pocos módulos concentran muchos defectos.

5️⃣ Las pruebas se desgastan

Si ejecutamos siempre las mismas pruebas:

• dejan de encontrar defectos nuevos

• pierden efectividad

Por eso los casos de prueba deben:

• actualizarse

• mejorarse

• variar escenarios

💡 Un set de pruebas viejo puede dar una falsa sensación de seguridad.

6️⃣ El testing depende del contexto

No se prueba igual:

• una app bancaria

• un videojuego

• un e-commerce

• un sistema médico

Cada proyecto tiene:

• riesgos distintos

• prioridades distintas

• usuarios distintos

👉 No existe una única forma correcta de testear.

7️⃣ La falacia de la ausencia de defectos

Un software puede no tener bugs…

y aun así ser un fracaso.

💡 Si no resuelve las necesidades del usuario, el producto falla igual.

Ejemplo:

• una app difícil de usar

• un sistema lento

• una funcionalidad que nadie necesita

👉 Calidad no significa solamente “sin errores”.

🧪 Tip para el examen ISTQB

En el examen suelen aparecer preguntas donde:

• te describen una situación

• y tenés que identificar qué principio se aplica

Mi recomendación:

❌ No memorices frases
✅ Entendé situaciones reales

Porque ahí es donde realmente se vuelven más fáciles de entender.

🚀 Para cerrar

Los principios del testing son importantes porque cambian la forma en la que vemos el software.

Testing no se trata de “probar todo”.

Se trata de:

• entender riesgos

• tomar decisiones inteligentes

• y ayudar a construir productos confiables.

💬 ¿Cuál de estos principios te parece más real en proyectos de verdad?

Si te interesan estos temas, no olvides suscribirte para recibir mis publicaciones directamente en tu bandeja de entrada 😉

Suscríbete ahora

En sus propias palabras nos explica de qué se trata:

“El problema principal al testear integraciones de IA o Chatbots es la variabilidad. Como las respuestas son generadas, casi nunca recibís el mismo string exacto dos veces. Si usás un assertEquals o un .toContainText() tradicional, el test se vuelve 'flaky' y falla por cosas como un sinónimo o un cambio de tono.
Lo que hice con playwright-ai-matchers fue cambiar el enfoque de validación:
1. Validación por Intención: En lugar de buscar texto rígido, el matcher le envía el contenido de la respuesta a un modelo de lenguaje (LLM) con una instrucción semántica.
2. Abstracción del DOM: No importa si la respuesta del bot está en un <span>, un <div> o si el texto está fragmentado. El matcher entiende el contexto visual y funcional.
3. Ejemplo práctico: Si testeás un bot que debe dar recomendaciones de inversión, podés validar:
•expect(botResponse).toConfirm('que el bot mencione los riesgos de mercado sin dar consejos financieros directos').
• No importa si el bot usa 50 o 100 palabras; si cumple con esa regla de negocio, el test pasa.
Está pensado para facilitar la vida cuando el 'Expected Result' no es una cadena de texto, sino un comportamiento o un concepto.”

En el siguiente video nos muestra cómo usarlo:

Link al repositorio → aquí

LinkedIn de Germán → aquí

En mi opinión, es muy buena herramienta a la hora de probar las respuestas de un chatbot. Ahora qué tal si la usamos para probar una web común 🤔

¿Qué te parece esta herramienta, la usarías? Te leo en comentarios.

Si te interesan estos temas y querés que analicemos una herramienta para Testing en particular, dejame un comentario y con gusto la veo.

No olvides suscribirte para recibir todas las novedades en tu bandeja de correo 😉

Suscríbete ahora

Herramientas que no solo sugieren código, sino que ejecutan tareas completas, generan pruebas y validan resultados.

Pero, ¿qué significa esto para el testing?

A lo largo del episodio exploro cómo este nuevo enfoque cambia el rol del tester: menos ejecución, más evaluación. Menos scripts, más criterio.

Porque cuando la IA empieza a tomar decisiones, el valor ya no está solo en automatizar… sino en entender qué vale la pena probar.

Si estás trabajando con herramientas de IA en desarrollo o testing, este episodio te invita a parar un momento y pensar qué está cambiando realmente.

🎧 Dale play y seguimos la conversación.

Suscríbete ahora

👉 Qué significa realmente “probar”
👉 Por qué el testing es esencial en cualquier desarrollo

El testing no es solo ejecutar pruebas, sino una actividad que busca evaluar la calidad, detectar defectos y reducir riesgos, ayudando a construir software confiable.

También vas a ver conceptos fundamentales que aparecen siempre en el examen, como:

• Verificación vs Validación

• Testing vs Debugging

• La cadena: Error → Defecto → Fallo

Y algo muy importante:
💡 Un sistema sin errores no necesariamente es un buen producto.

🎥 En el video te explico todo esto con ejemplos y preguntas reales de examen para que lo entiendas de forma práctica.

🚀 Si estás preparando el ISTQB, esta es la base de todo lo demás.

Suscríbete ahora

NotebookLM con material de ISTQB → AQUÍ

Video resumen del material de ISTQB generado por NotebookLM:

🎤 Audio estilo podcast generado por NotebookLM sobre el mismo material:

Si llegaste hasta acá, en la próxima entrega hablaremos de los principios de testing!

👉 Hoy te presento Tero, un framework open-source creado por Abstracta.

Si Antigravity nos mostraba el potencial de la IA aplicada al testing, Tero baja esa idea a algo mucho más concreto:

la posibilidad de crear agentes de IA que trabajen con nosotros en el día a día.

Pero vamos por partes.

🔹 ¿Qué es Tero?

En simple: es una base para crear agentes de inteligencia artificial que pueden integrarse con tu entorno de trabajo.

No es solo una herramienta que “te sugiere cosas”, sino algo más potente:
estos agentes pueden conectarse a tu código, logs o pipelines y ayudarte a:

✔ generar tests
✔ analizar errores
✔ entender qué está pasando en el sistema
✔ validar releases

🔹 ¿Qué lo hace diferente?

Una de las ideas clave era que la IA no viene solo a automatizar tareas, sino a entender contexto.

Y eso es justamente lo que intenta resolver Tero.

No es automatización tradicional.
No es solo scripts más rápidos.

👉 Es un cambio de enfoque: pasar de ejecutar a interpretar.

🔹 Open-source y adaptable

Otro punto interesante es que Tero es open-source.

Esto significa que no estás limitado a lo que una herramienta comercial decide hacer, sino que podés adaptarlo a tu realidad como tester o equipo.

En un momento donde están apareciendo muchas soluciones cerradas de IA, esto no es menor.

🔹 ¿Por qué importa esto como testers?

Porque estamos viendo un cambio claro:

Antes:

• escribíamos tests

• ejecutábamos

• analizábamos resultados

Ahora:

• empezamos a apoyarnos en IA para pensar mejor, no solo para ejecutar

Y herramientas como Tero van en esa dirección.

💡 Mi reflexión

Aunque todavía estamos en una etapa temprana, todo indica que este tipo de herramientas van a formar parte de nuestro día a día más pronto de lo que pensamos.

🎥 Ver Tero en acción

Para que todo esto no quede solo en lo conceptual, grabé dos videos donde podés ver cómo funciona Tero en la práctica.

🔹 Video 1: Primeros pasos con Tero

En este video te muestro:

✔ cómo instalar Tero en local
✔ sus pantallas básicas
✔ un primer recorrido para entender cómo está estructurada la herramienta

La idea es que puedas tener un primer contacto sin complicarte.

🔹 Video 2: Experiencia real + uso de agentes

En este segundo video conversamos con Lucas del Reguero Martínez, quien viene usando Tero desde que se liberó el año pasado en la Quality Sense Conf.

Además de usarla desde el inicio, ha hecho aportes muy interesantes como usuario, ayudando a mejorar la herramienta desde una mirada práctica (y esto me parece súper valioso, porque no es parte de Abstracta).

En el video vas a ver:

✔ cómo empezar a trabajar con agentes
✔ ejemplos de uso reales
✔ insights desde la experiencia

💡 Si te interesa explorar IA aplicada al testing, te recomiendo ver ambos:

• el primero para entender la base

• el segundo para ver el potencial real en acción

Y después contame: ¿cómo imaginás que te puede ayudar algo así en tu día a día? 🤔

🔹 Video 1: Primeros pasos con Tero

🔹 Video 2: Experiencia real + uso de agentes

🔗Links importantes

👉🏻 Accede al repositorio de Tero aquí.

👉🏻 Accede al repositorio de Agentes aquí.

👉🏻 Accede a la POC de Testing Exploratorio con agente Wally Explorer de Lucas aquí.

👉🏻 Si te interesa conectar con Lucas podes encontrar su LinkedIn aquí.

Actividades de Abril

¿Nos vemos en la TestingUY?

Suscríbete ahora

Ahora sí, te adelanto lo que vas a encontrar en las próximas semanas 👇

🔹 Viernes 10 de abril
Voy a estar compartiendo un post sobre una herramienta de IA que me resulta muy interesante: Tero, de Abstracta. Si te interesa el testing y cómo la inteligencia artificial puede potenciarlo, este contenido es para vos.

🔹 Viernes 17 de abril
Se viene un nuevo capítulo sobre ISTQB Foundation Level, ideal si estás estudiando o querés reforzar conceptos clave de testing.

🔹 Viernes 24 de abril
Publico el segundo episodio del podcast “Testing con criterio”, donde sigo profundizando en temas prácticos y reflexiones del día a día en testing.

Me entusiasma mucho lo que se viene este mes y espero que estos contenidos te aporten valor, ya sea que estés empezando en IT o quieras seguir creciendo profesionalmente.

¡Nos leemos pronto! 🚀

Suscríbete ahora

En este primer episodio te comparto por qué nace Testing con Criterio y qué significa realmente desarrollar una mirada profesional más profunda.

Vamos a hablar de fundamentos, certificaciones, herramientas con IA y, sobre todo, de pensamiento crítico aplicado al testing.

Este es el comienzo de una conversación que recién empieza.

🎧 Dale play y empezamos.

Si este episodio te resonó, podés suscribirte para recibir los próximos y sumarte a la conversación.
Me interesa leer tu opinión: ¿qué significa para vos tener criterio en testing?

Suscríbete ahora

❌ No es un curso.
❌ No es un resumen del syllabus.
❌ Y no es contenido para memorizar definiciones.

La idea de esta sección es algo mucho más simple (y más necesario): entender los fundamentos del testing y conectarlos con la práctica real, incluso —y especialmente— en un contexto donde la IA parece hacerlo todo más rápido.

¿Por qué ISTQB ahora?

Porque en los últimos años vi un patrón repetirse:

• automatización sin criterio,

• tests generados que nadie entiende,

• herramientas potentes usadas sin base conceptual.

El Foundation Level, con todas sus limitaciones, sigue ofreciendo algo valioso: un lenguaje común y una forma de pensar el testing. El problema no es la certificación en sí, sino cómo se estudia y cómo se aplica.

En esta sección voy a hablar de:

• conceptos del syllabus llevados a ejemplos reales,

• errores comunes al estudiar y rendir el examen,

• qué partes siguen siendo útiles hoy,

• y cuáles quedan cortas frente a la realidad actual.

La frecuencia va a ser un post el segundo viernes de cada mes.
Tranquilo, claro y aplicable.

Si estás estudiando para el ISTQB FL, o si alguna vez lo rendiste y sentís que quedó desconectado de tu día a día, esta sección es para vos 😉

Suscríbete ahora

Más allá del ruido inicial, vale la pena detenerse y mirar con criterio qué está cambiando realmente.

Porque no se trata solo de que la IA escriba código más rápido.

Se trata de algo más profundo.

🤖 ¿Qué es Antigravity?

Antigravity es una plataforma experimental impulsada por Google que propone un enfoque diferente: en lugar de asistentes que sugieren fragmentos de código, trabaja con agentes autónomos capaces de:

• planificar tareas

• ejecutar cambios

• interactuar con el entorno (editor, terminal, navegador)

• validar resultados

Todo esto apoyado en modelos como Gemini, que permiten mayor comprensión de contexto y ejecución más compleja.

La promesa es clara: pasar de “copilotos” a sistemas que orquestan partes del flujo de desarrollo.

Y acá es donde el testing empieza a volverse interesante.

🧪 ¿Qué cambia para el testing?

Si el desarrollo empieza a ser agent-first, el testing no puede seguir siendo simplemente script-first.

Veamos algunos puntos clave.

1️⃣ Generación automática de pruebas

Si un agente puede:

• implementar una funcionalidad

• ejecutar flujos en el navegador

• validar respuestas

Entonces también puede:

• generar casos de prueba

• crear scripts automatizados

• ejecutar validaciones básicas

Esto puede acelerar muchísimo el arranque de una suite automatizada.

Pero aparece la pregunta esencial:

👉 ¿Quién valida que esas pruebas cubren realmente el riesgo?

La IA puede ejecutar.
El tester debe evaluar.

2️⃣ El rol del tester como auditor de agentes

Cuando el desarrollo es asistido o incluso ejecutado por agentes autónomos, el tester ya no solo prueba código humano.

Empieza a auditar decisiones tomadas por un sistema inteligente.

Eso implica:

• analizar cómo se interpretaron los requerimientos

• revisar si los criterios de aceptación fueron comprendidos correctamente

• detectar supuestos implícitos que la IA no cuestionó

En este escenario, el valor diferencial no está en escribir más scripts.

Está en pensar mejor.

3️⃣ El riesgo de la falsa confianza

Cuando un sistema genera:

• código

• pruebas

• validaciones

• evidencia automática

Puede dar la sensación de que “todo está cubierto”.

Pero cobertura no es calidad.
Ejecución no es criterio.

Y este punto es clave.

Porque mientras más sofisticadas sean las herramientas, más importante se vuelve la capacidad humana de cuestionar.

4️⃣ Una oportunidad real para testers técnicos

Para perfiles más técnicos, herramientas como Antigravity pueden ser aliadas potentes:

• acelerar generación de escenarios

• proponer estructuras de automatización

• crear datos de prueba

• sugerir validaciones iniciales

Pero el diferencial estará en:

• refinar

• ampliar

• desafiar

• detectar lo que el agente no vio

No en aceptar automáticamente lo que produce.

🧠 Una reflexión necesaria

Estamos entrando en una etapa donde el desarrollo puede ser cada vez más automatizado.

Pero eso no elimina la necesidad de pensamiento crítico.

Al contrario.

Si el desarrollo empieza a ser agent-first, el testing no puede ser automático por defecto.

Necesitamos testers capaces de:

• entender el contexto

• evaluar riesgos

• cuestionar decisiones

• supervisar sistemas inteligentes

Porque la automatización ejecuta.

Pero el criterio evalúa.

📡 Radar de marzo – IA y testing

Si querés profundizar en estos temas, durante marzo hay varios eventos y webinars online sobre IA aplicada al desarrollo y testing. Vale la pena seguirlos para entender hacia dónde evoluciona el ecosistema.

• 11/03/26 Inteligencia Artificial para el bien - Teatro Solis - Montevideo

Microsoft invita a socios de la CUTI a sumarse a esta invitación del AI for Good Lab el Miércoles 11 de Marzo en el Teatro Solis. Podes reservar tu lugar gratis aquí.

• 20/03/26 AI Testing Talks (Webinar online en inglés)

Why QA teams are adopting Playwright and how AI makes it smarter

Un webinar enfocado en IA aplicada al testing con temas como Playwright y cómo la IA mejora flujos de pruebas modernas. Podes ver más información del evento aquí.

💡 Si participás en alguno, contame tu experiencia. Me interesa sumar miradas reales desde la práctica.

No fue una pausa para desconectarme del todo, sino para frenar el ritmo, revisar lo que escribí, lo que aprendí y, sobre todo, decidir cómo quiero seguir. El año pasado publiqué 35 posts, probé herramientas, exploré IA aplicada al testing y confirmé algo importante: no quiero escribir para seguir el ritmo del hype, sino para pensar mejor mi trabajo.

Este año quiero un Substack más organizado, más intencional y más sostenible. Menos novedad, más criterio.

Por eso, a partir de ahora:

• voy a publicar acá el primer viernes de cada mes,

• algunos posts estarán enfocados en IA y automatización,

• otros en fundamentos de testing en una nueva sección para tratar temas del ISTQB, que saldrán el tercer viernes de cada mes,

• y también habrá espacio para reflexión profesional.

Además, sumo algo nuevo: un podcast. No como un proyecto aparte, sino como otro formato para pensar en voz alta. Un espacio más libre para conectar herramientas actuales, fundamentos clásicos (como ISTQB) y experiencia real. Los episodios saldrán el último viernes de cada mes.

En síntesis, vuelvo con una intención clara: escribir y hablar sobre testing con criterio, en un contexto que cambia todo el tiempo.

Gracias por estar del otro lado.
Arrancamos marzo 😉

Suscríbete ahora

Y llegó casi sin avisar.
No sé si a vos te pasó lo mismo, pero este año se me fue volando. Cuando quise darme cuenta, ya estaba mirando hacia atrás, haciendo balance y preguntándome en qué momento escribí tanto. 😱

Durante este año publiqué 35 posts. Algunos nacieron de ideas muy claras, otros de preguntas, pruebas, dudas o momentos personales. Todos, sin excepción, fueron escritos con la intención de compartir, reflexionar y explorar cómo la tecnología —y en especial la IA— está transformando nuestra forma de trabajar. 🔍

Mirando el recorrido, hay algo que me sorprendió y me alegró mucho: varios contenidos tuvieron una recepción enorme. Estos son algunos de los posts que superaron las 300 vistas, lo que me confirmó que hay una curiosidad real y creciente por estos temas:

• Healenium: La herramienta que automatiza la curación de tus tests

• Testsigma: Automatización de pruebas no-code

• ¿Pueden las IA generar buenos casos de prueba? Las comparé con una misma historia de usuario

• Probando APIs con ayuda de la IA de Postman: generación automática de tests en JavaScript

• Qodex.ai: API testing inteligente con generación automática de pruebas y plan gratuito

• TestCraft API Agent: Generando pruebas automáticas desde OpenAPI con IA

• ¿Qué son los MCP Servers y por qué están cambiando la forma de probar aplicaciones con IA?

• Explorando Playwright MCP Server: automatización UI controlada por LLMs

• MCP Servers para testing: los más útiles hoy

• Coding Fleet: La herramienta de IA que convierte tu código entre frameworks y lenguajes

Ver este interés fue un gran empujón para seguir escribiendo, investigando y probando herramientas, incluso cuando el tiempo escaseaba.

Por eso quiero agradecerte si estuviste del otro lado: leyendo, comentando, compartiendo o simplemente guardando algún post para más adelante. Y un gracias especial a quienes se suscribieron y acompañaron el proyecto durante el año. Substack no es solo una plataforma; es una pequeña comunidad que se construye palabra a palabra. 🙏🏻

Ahora siento que es momento de algo distinto.
Voy a tomarme un par de meses de pausa consciente.

No es un descanso para desaparecer, sino un tiempo para pensar con calma, revisar lo recorrido y decidir qué quiero hacer y crear el próximo año. Qué temas profundizar, cuáles reformular, y qué forma darle a este espacio para que siga teniendo sentido, tanto para mí como para quienes lo leen.

A veces, frenar también es una forma de avanzar.

Gracias por acompañar este año de escritura, pruebas, ideas y aprendizaje compartido. Nos volveremos a encontrar con energía renovada, más claridad y nuevas preguntas que valga la pena explorar. 🤗

Que el cierre de este año también te regale un momento de pausa 🤍