Hay experiencias que nos permiten aprender cosas nuevas. Otras nos conectan con personas, comunidades y oportunidades que dejan huella.

Y algunas nos permiten vivir desde otro lugar algo que, hasta ese momento, habíamos conocido como participantes.

El pasado 13 de octubre tuve la oportunidad de ser, por primera vez, parte del staff de Abstracta en Quality Sense Conf, una conferencia de nivel internacional que tiene un lugar muy importante en la comunidad tecnológica de nuestra región.

Y quería dedicar unas líneas a contarles esa experiencia.

Ser parte del equipo que hace posible un evento de estas características me permitió vivir la conferencia desde otra perspectiva. Detrás de cada encuentro, cada charla y cada espacio de intercambio hay personas que trabajan para que todo suceda, y haber podido aportar mi granito de arena fue algo que valoro muchísimo.

Creo que los espacios como Quality Sense Conf tienen un valor enorme para nuestra comunidad. Nos permiten compartir conocimientos, conocer otras experiencias, descubrir nuevas ideas y seguir construyendo una industria en la que aprender de otros y crecer juntos sea parte del camino.

Pero también nos recuerdan algo importante: una comunidad no se construye solamente desde el escenario. Se construye con cada persona que comparte lo que sabe, con quienes organizan, colaboran, acompañan y hacen posible que estos encuentros sucedan.

Esta vez me tocó vivirlo desde adentro, y me llevo el agradecimiento por haber sido parte.

A veces, crecer profesionalmente también significa animarse a ocupar nuevos lugares y descubrir todo lo que podemos aprender cuando nos damos la oportunidad de hacerlo.

¡Gracias equipo!

Y si te interesa revisar nuevamente las charlas o si te las perdiste, te dejo los links 👇🏻

👉🏻 Mira el track general aqui

👉🏻 Mira el track de testing aqui

Si te gustaría tener un resumen escrito o incluso pedirle al chat que te de los temas mas importantes de cada charla, cree un NotebookLM con ambos tracks al que podes acceder aquí.

Si te interesan estos temas, suscíbete 😉

Suscríbete ahora

“Es un cambio pequeño. No hace falta probar todo de nuevo.”

¿Cuántas veces escuchamos —o pensamos— algo parecido?

Se cambia una regla de negocio.
Se actualiza una versión.
Se corrige un error urgente.
Se migra una base de datos.
Se modifica una integración.

Y aparece la pregunta:

¿Qué tenemos que probar ahora?

Esta es justamente una de las preguntas que aborda el Maintenance Testing, el testing que realizamos cuando un sistema que ya está operativo cambia, se actualiza o está siendo retirado.

Y acá aparece algo muy importante:

un cambio pequeño en el código no necesariamente significa un cambio pequeño en el comportamiento del sistema.

¿Qué es Maintenance Testing?

Las pruebas de mantenimiento se realizan sobre un sistema que ya está en funcionamiento cuando se producen determinados cambios.

Por ejemplo:

• se agregan o modifican funcionalidades;

• se corrigen defectos;

• se realizan actualizaciones;

• se migra el sistema a otro entorno o plataforma;

• se realizan cambios para adaptarlo a un nuevo contexto;

• se mejora el rendimiento o la mantenibilidad;

• o incluso cuando se retira un sistema.

Es decir, el testing no termina cuando la aplicación sale a producción.

Mientras el sistema siga evolucionando, seguimos necesitando probarlo.

¿Cuándo necesitamos hacer pruebas de mantenimiento?

Podemos encontrarnos con diferentes situaciones.

1. Cambios en el sistema

Supongamos que tenemos una tienda online y el negocio decide modificar la forma en que se calculan los descuentos.

Parece sencillo:

“Solo cambiamos la fórmula del descuento.”

Pero ese cálculo podría utilizarse también para:

• el total de la compra;

• las facturas;

• los reportes;

• los emails de confirmación;

• las promociones;

• los límites de descuentos;

• la información mostrada al cliente.

El cambio estaba en un lugar.

El impacto puede estar en muchos lugares.

2. Actualizaciones o migraciones

También necesitamos testing cuando cambiamos el entorno en el que funciona nuestro sistema.

Por ejemplo:

• actualización de una versión de base de datos;

• cambio de sistema operativo;

• actualización de una librería;

• migración a otro servidor;

• cambio de infraestructura;

• migración de datos;

• actualización de un servicio externo.

Aunque nuestro código de negocio no haya cambiado demasiado, el contexto en el que se ejecuta sí cambió.

Y eso puede generar comportamientos inesperados.

3. Retiro de un sistema

Sí.

Incluso cuando vamos a retirar un sistema puede ser necesario realizar testing.

Por ejemplo, necesitamos asegurarnos de que:

• los datos fueron correctamente archivados;

• la información que debe conservarse puede recuperarse;

• las integraciones fueron correctamente desconectadas;

• no quedaron procesos dependientes del sistema anterior.

Retirar una aplicación también forma parte de su ciclo de vida.

Antes de cambiar: análisis de impacto

Acá aparece uno de los conceptos que considero más interesantes de este tema:

Impact Analysis — Análisis de impacto.

Antes de realizar un cambio podemos analizar qué partes del sistema podrían verse afectadas.

Esto nos ayuda a responder preguntas como:

• ¿Qué funcionalidades utilizan este componente?

• ¿Qué otros sistemas dependen de él?

• ¿Qué pruebas podrían verse afectadas?

• ¿Qué áreas deberíamos volver a probar?

• ¿Qué riesgos introduce este cambio?

Porque una de las peores estrategias sería pensar:

“Modificamos este método, entonces solamente probamos este método.”

En sistemas reales, las dependencias pueden ser mucho más complejas.

¿Y qué pasa con la regresión?

Acá aparece otro concepto fundamental:

Regression Testing — Pruebas de regresión.

Cuando realizamos un cambio, no solamente queremos comprobar que el cambio funciona.

También queremos asegurarnos de que no rompimos algo que antes funcionaba.

Por ejemplo:

Tenemos una aplicación de compras.

Modificamos el cálculo de descuentos.

Primero podemos comprobar:

“¿El nuevo cálculo funciona correctamente?”

Pero también necesitamos preguntarnos:

“¿Qué pasó con el resto de la aplicación?”

¿Se siguen calculando correctamente los impuestos?

¿El total de la compra continúa siendo correcto?

¿La factura muestra los valores esperados?

¿Los reportes siguen funcionando?

¿Las promociones existentes continúan aplicándose correctamente?

Ahí entra la regresión.

Confirmación y regresión no son lo mismo

Esta diferencia es muy útil.

Prueba de confirmación:

¿La corrección o cambio específico funciona como esperamos?

Prueba de regresión:

¿El cambio introdujo nuevos problemas en funcionalidades que antes funcionaban?

Podemos necesitar ambas.

Por ejemplo, si corregimos un defecto en el cálculo de impuestos:

Confirmación:
comprobamos que el defecto efectivamente quedó solucionado.

Regresión:
comprobamos que la modificación no afectó otros cálculos relacionados.

¿Tenemos que probar absolutamente todo?

Y acá llegamos a una pregunta muy interesante clave.

Si una aplicación tiene miles de pruebas, ¿cada vez que hacemos un cambio debemos ejecutar las miles?

No necesariamente.

El alcance del Maintenance Testing depende de diferentes factores, entre ellos:

• el riesgo asociado al cambio;

• el tamaño y complejidad del sistema existente;

• el tamaño del cambio;

• las áreas potencialmente afectadas;

• el contexto en el que estamos trabajando.

Por eso el análisis de impacto y la evaluación de riesgos son tan importantes.

No se trata simplemente de ejecutar más pruebas.

Se trata de elegir qué pruebas tienen más sentido.

Un ejemplo muy común

Imaginemos que tenemos una aplicación bancaria.

Se modifica una pequeña parte del código relacionada con las transferencias.

Podríamos pensar:

“Solo cambiamos una validación.”

Pero esa validación puede estar relacionada con:

• transferencias nacionales;

• transferencias internacionales;

• límites diarios;

• notificaciones;

• movimientos de cuenta;

• reportes;

• auditoría.

Entonces aparece una pregunta mucho más interesante que:

“¿Qué código cambió?”

La pregunta debería ser:

“¿Qué comportamiento del sistema podría verse afectado por este cambio?”

Ese cambio de perspectiva es fundamental para hacer testing con criterio.

¿Y la automatización?

Las pruebas de regresión son, además, una de las áreas donde la automatización puede aportar muchísimo valor.

¿Por qué?

Porque muchas pruebas de regresión deben ejecutarse repetidamente a lo largo del tiempo.

Si tenemos una suite automatizada, podemos ejecutarla después de diferentes cambios para obtener feedback rápidamente.

Pero cuidado con una idea:

“Tenemos automatización, entonces estamos cubiertos.”

No necesariamente.

Una suite automatizada también puede:

• estar desactualizada;

• no cubrir determinados riesgos;

• contener pruebas poco útiles;

• no contemplar nuevos escenarios;

• pasar y aun así dejar problemas sin detectar.

La automatización ayuda.

Pero la estrategia de testing sigue siendo necesaria.

Testing con criterio

Para mí, una de las enseñanzas más importantes de Maintenance Testing es esta:

un cambio no se evalúa solamente mirando lo que modificamos.

Tenemos que pensar en:

Cambio → Impacto → Riesgo → Pruebas

Y eso nos lleva nuevamente a una idea que aparece constantemente en testing:

No podemos probar todo de la misma manera ni con la misma profundidad.

Un cambio crítico en una funcionalidad financiera probablemente merece un análisis diferente al de un cambio visual menor.

Una migración de base de datos requiere otro enfoque.

Un hotfix urgente puede necesitar una estrategia diferente a una nueva funcionalidad planificada.

El contexto importa.

Y entonces… ¿cuándo termina el testing?

Esta es quizás la pregunta que más me gusta dejar después de hablar de mantenimiento.

Una aplicación no queda congelada cuando llega a producción.

Los sistemas cambian.

Los usuarios cambian.

Las reglas de negocio cambian.

Las tecnologías cambian.

Los entornos cambian.

Y nosotros, como testers, tenemos que acompañar esos cambios.

Por eso Maintenance Testing no significa simplemente:

“Volver a probar la aplicación.”

Significa analizar qué cambió, qué podría verse afectado y qué necesitamos probar para obtener suficiente confianza en el sistema.

Y ahí vuelve a aparecer algo que atraviesa todo el testing:

Testear no es ejecutar pruebas sin pensar.

Es tomar decisiones basadas en riesgo, impacto y contexto.

Para pensar

La próxima vez que alguien diga:

“Es un cambio pequeño, probemos rápido y listo.”

Quizás la pregunta no sea:

“¿Cuántas pruebas vamos a ejecutar?”

Sino:

“¿Qué podría romperse como consecuencia de este cambio?”

Porque a veces el cambio más pequeño puede tener un impacto mucho más grande de lo que imaginamos.

Y justamente ahí es donde entra el Maintenance Testing.

Testing con Criterio.

¿Y vos?

¿Alguna vez te pasó que un cambio aparentemente pequeño terminó afectando una funcionalidad que nadie esperaba?

Te leo en los comentarios.

Si te interesan estos temas, suscríbete!

Suscríbete ahora

Hablamos de:

• Qué es testing y por qué es necesario.

• Los principios del testing.

• Las actividades, el testware y los roles.

• Las habilidades necesarias para trabajar en testing.

• Y más recientemente, cómo el testing se relaciona con el Software Development Lifecycle (SDLC).

Ahora damos un paso más dentro del syllabus.

Llegamos al apartado 2.2 – Test Levels and Test Types.

Y acá aparece una distinción que puede parecer sencilla, pero que muchas veces genera confusión:

Un nivel de prueba no es lo mismo que un tipo de prueba.

Vamos a verlo.

Primero: ¿qué es un Test Level?

Los test levels o niveles de prueba son grupos de actividades de testing que se organizan y gestionan conjuntamente y que están relacionados con una determinada etapa o ámbito del desarrollo del software. ISTQB describe cinco niveles de prueba en el Foundation Level v4.0.1.

Los cinco niveles son:

1. Component Testing o Pruebas de componentes

2. Component Integration Testing o Pruebas de integración de componentes

3. System Testing o Pruebas de sistema

4. System Integration Testing o Pruebas de integración de sistemas

5. Acceptance Testing o Pruebas de aceptación

Cada uno tiene un objetivo diferente.

1. Component Testing o Pruebas de componentes

Empezamos por la unidad más pequeña que podemos probar.

El Component Testing o Pruebas de componentes se concentra en componentes individuales.

Por ejemplo:

• Una función.

• Una clase.

• Un módulo.

• Un componente de una aplicación.

En este nivel normalmente buscamos comprobar que ese componente se comporte correctamente de manera aislada.

Un ejemplo típico serían los unit tests.

Imaginemos una función que calcula el precio final de una compra.

Podemos probar diferentes entradas:

• Precio positivo.

• Descuento válido.

• Descuento igual a cero.

• Valores límite.

• Datos inválidos.

Todavía no estamos preocupándonos por toda la aplicación.

Estamos concentrándonos en ese componente.

2. Component Integration Testing o Pruebas de integración de componentes

Ahora tenemos varios componentes que necesitan trabajar juntos.

Y aparece una nueva pregunta:

¿Funcionan correctamente cuando se comunican entre ellos?

Acá entran en juego las interfaces e interacciones entre componentes.

Por ejemplo:

🛒 Carrito
      ↓
💰 Servicio de precios
      ↓
🎟️ Servicio de descuentos

Cada componente puede funcionar perfectamente de manera individual.

Pero cuando los conectamos...

💥 puede aparecer un problema.

Un formato de datos incorrecto.

Un parámetro que no se envía como esperamos.

Una respuesta que no se interpreta correctamente.

Por eso necesitamos probar la integración.

3. System Testing o Pruebas de sistema

Ahora damos un paso atrás.

Ya no queremos comprobar solamente componentes.

Queremos evaluar el sistema completo.

Por ejemplo, en una tienda online podríamos probar:

Login
  ↓
Buscar producto
  ↓
Agregar al carrito
  ↓
Aplicar descuento
  ↓
Realizar pago
  ↓
Confirmar compra

Acá podemos evaluar el comportamiento completo del sistema y comprobar si cumple con los requisitos definidos.

Y aparece una idea importante:

El sistema puede estar formado por componentes que funcionan correctamente y, aun así, presentar problemas cuando se comporta como un todo.

4. System Integration Testing o Pruebas de integración de sistemas

Ahora aparece otro tipo de integración.

No solamente tenemos componentes dentro de nuestro sistema.

También podemos tener sistemas externos.

Por ejemplo:

Nuestra aplicación
       ↓
API de pagos
       ↓
Banco

O:

Nuestra aplicación
       ↓
Servicio de email
       ↓
Proveedor externo

El objetivo del System Integration Testing es comprobar las interacciones entre el sistema que estamos probando y otros sistemas o servicios.

Y en los sistemas modernos esto se vuelve especialmente importante.

Porque cada vez tenemos más APIs, microservicios, proveedores externos y sistemas distribuidos.

5. Acceptance Testing o Pruebas de aceptación

Llegamos al último nivel.

Ahora la pregunta cambia:

¿El sistema satisface las necesidades de los usuarios y otros stakeholders?

El Acceptance Testing está relacionado con evaluar si el sistema está listo para ser aceptado.

Dependiendo del contexto, pueden participar:

• Usuarios.

• Clientes.

• Product Owners.

• Representantes del negocio.

• Otros stakeholders.

Acá aparece una perspectiva diferente.

No estamos preguntando solamente:

“¿Funciona?”

También estamos preguntando:

“¿Es lo que necesitamos?”

Entonces… ¿qué es un Test Type?

Hasta ahora hablamos de dónde o en qué nivel estamos probando.

Pero ahora aparece otra pregunta:

¿Qué característica o aspecto queremos evaluar?

Ahí entran los test types o tipos de prueba.

Entre los principales tipos encontramos:

Functional Testing o Pruebas funcionales

Busca evaluar si el sistema hace lo que debería hacer.

Por ejemplo:

• Crear un usuario.

• Realizar una compra.

• Calcular un descuento.

• Generar un reporte.

Non-Functional Testing o Pruebas no funcionales

Se concentra en características de calidad diferentes de la funcionalidad.

Por ejemplo:

• Performance.

• Usabilidad.

• Seguridad.

• Compatibilidad.

Una aplicación puede hacer exactamente lo que debería hacer...

pero ser extremadamente lenta.

Y entonces tenemos un problema de calidad.

Black-Box Testing o Pruebas de caja negra

Las pruebas se diseñan a partir de la especificación o del comportamiento esperado, sin necesidad de conocer la implementación interna del software.

El foco está en:

Qué hace el sistema.

White-Box Testing Pruebas de caja blanca

Acá utilizamos información sobre la estructura o implementación interna del software.

El foco está en:

Cómo está construido el sistema.

Por ejemplo, podemos analizar qué caminos del código están siendo ejecutados por nuestras pruebas.

Y acá aparece una idea clave

Los test levels y los test types no son alternativas.

Se pueden combinar.

Por ejemplo, podemos tener:

System Testing + Functional Testing

o:

System Testing + Performance Testing

o:

Component Testing + Functional Testing

o:

System Integration Testing + Security Testing

Esto es importante porque nos permite entender que estamos hablando de dos dimensiones diferentes.

Una responde:

¿En qué nivel estamos probando?

La otra:

¿Qué queremos evaluar?

Un ejemplo práctico

Imaginemos una aplicación de e-commerce.

Podríamos tener:

NivelEjemploComponent TestingProbar el cálculo del precioComponent Integration TestingProbar carrito + descuentosSystem TestingProbar el proceso completo de compraSystem Integration TestingProbar integración con el proveedor de pagosAcceptance TestingValidar que el proceso responde a las necesidades del negocio

Y dentro de esos niveles podemos aplicar diferentes tipos de testing.

Por ejemplo:

System Testing + Functional

→ ¿Podemos completar correctamente una compra?

System Testing + Performance

→ ¿El sistema soporta 10.000 usuarios concurrentes?

System Testing + Security

→ ¿Los datos del usuario están protegidos?

Mismo sistema.

Distinto objetivo.

¿Por qué es importante entender esta diferencia?

Porque en un proyecto real, cuando alguien dice:

“Ya hicimos testing.”

La pregunta debería ser:

¿Qué testing hicimos?

¿Qué nivel?

¿Qué tipo?

¿Qué riesgos cubrimos?

¿Qué quedó fuera?

Decir simplemente “hicimos testing” no nos dice demasiado.

Necesitamos contexto.

Y esto vuelve a conectarnos con algo que vimos en el artículo anterior:

El testing debe adaptarse al contexto.

No existe una única estrategia que funcione para todos los productos.

Una pequeña regla para recordarlo

Si estás preparando el examen ISTQB, puedes pensar en esta pregunta:

Test Level

¿Dónde / qué ámbito estamos probando?

Component → Integration → System → Acceptance

Test Type

¿Qué característica o aspecto estamos evaluando?

Functional → Non-functional → otros enfoques según el objetivo.

Esta separación mental ayuda muchísimo.

Testing con criterio

Para mí, esta es una de las partes más interesantes del syllabus.

ISTQB no nos está diciendo simplemente:

“Aprende estos cinco niveles y estos tipos de prueba.”

Nos está enseñando a pensar.

Cuando recibimos una nueva funcionalidad deberíamos preguntarnos:

¿Qué nivel necesito probar?

¿Qué tipo de prueba necesito realizar?

¿Qué riesgos estoy intentando cubrir?

¿Qué información necesito para tomar una decisión?

Ahí empieza el verdadero testing con criterio.

Para cerrar

Los niveles de prueba nos ayudan a organizar dónde y en qué ámbito probamos.

Los tipos de prueba nos ayudan a definir qué aspecto o característica queremos evaluar.

Y cuando combinamos ambos conceptos podemos construir una estrategia mucho más completa.

Porque probar no es simplemente ejecutar casos.

Es entender:

qué estamos probando, por qué lo estamos probando y qué información necesitamos obtener.

💬 Para reflexionar

Te dejo una pregunta:

Cuando en tu equipo dicen “hay que hacer testing”, ¿se define claramente qué nivel y qué tipo de pruebas se necesitan?

¿O simplemente empezamos a ejecutar casos?

Te leo en los comentarios.

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

¿Cómo podemos mejorar la calidad?
¿Cómo podemos aprender de otros profesionales?
¿Cómo cambia nuestro trabajo con la llegada de nuevas tecnologías?
¿Y qué lugar seguimos ocupando las personas en todo este proceso?

Por eso, este mes quiero hacer una invitación especial a quienes forman parte de la comunidad de testing, QA y calidad de software: nos encontramos en Quality Sense Conf 2026.

El próximo 13 de octubre, Montevideo vuelve a ser punto de encuentro para profesionales de Uruguay, Latinoamérica y otros lugares del mundo que trabajan y piensan sobre la calidad del software.

El lema de esta edición es especialmente interesante:

“Construyendo confianza en la era de la IA”.

Y creo que no podría ser más actual.

La inteligencia artificial ya está cambiando la manera en que desarrollamos, testeamos y entregamos software. Pero la pregunta no es solamente qué herramientas podemos utilizar.

También tenemos que preguntarnos:

¿Cómo aseguramos la calidad cuando cada vez más parte del proceso está asistida por IA?

¿Qué decisiones siguen necesitando nuestro criterio como profesionales?

¿Cómo construimos confianza en sistemas que son cada vez más complejos?

Y, sobre todo, ¿cómo hacemos para que la tecnología nos ayude a ser mejores profesionales en lugar de simplemente hacer más cosas más rápido?

Un espacio para aprender, pero también para encontrarnos

Una conferencia no son solamente las charlas.

También están esas conversaciones que aparecen durante un coffee break.

El intercambio de experiencias con alguien que trabaja en otro país.

Una pregunta que te hace replantearte algo que dabas por sentado.

Un contacto que después termina convirtiéndose en una colaboración.

Quality Sense Conf nació justamente alrededor de esa idea de comunidad y, desde 2022, ha ido creciendo hasta convertirse en un punto de encuentro para quienes trabajan en calidad de software en Latinoamérica y el mundo.

¿Por qué creo que vale la pena estar?

Porque estamos atravesando un momento especialmente interesante para nuestra profesión.

Testing está cambiando.

QA está cambiando.

La ingeniería de calidad está cambiando.

Y la inteligencia artificial está acelerando muchos de esos cambios.

La QSConf 2026 propone justamente conversar sobre estas transformaciones, con speakers internacionales y espacios dedicados a temas como IA aplicada, Quality Intelligence, calidad de software y criterio humano.

Pero no hace falta tener todas las respuestas para participar.

De hecho, creo que es justamente al revés.

Tenemos que estar dispuestos a hacer preguntas.

A escuchar otras experiencias.

A compartir lo que nos funcionó —y también lo que no funcionó—.

Y a pensar juntos cómo queremos que sea el futuro de nuestra profesión.

Una agenda para explorar

Otro de los puntos interesantes de esta edición es la variedad de charlas y speakers que forman parte de la conferencia.

En lugar de intentar resumir toda la agenda acá, te invito a entrar al sitio oficial de Quality Sense Conf 2026 y mirar las sesiones, los temas y los speakers que van a participar.

Seguramente encuentres más de una charla que te interese, especialmente si estás siguiendo de cerca temas como inteligencia artificial, calidad de software, automatización, ingeniería de calidad y el futuro de nuestra profesión.

👉 Mirá la agenda y conocé a los speakers de Quality Sense Conf 2026

Nos vemos en QSConf

La conferencia será presencial en Montevideo y la entrada es gratuita, la invitación está abierta a quienes forman parte de la comunidad de testing, QA, calidad de software, desarrollo e ingeniería.

Si trabajás en testing, QA, software quality, desarrollo, producto o ingeniería, creo que puede ser una excelente oportunidad para aprender, compartir y conectar con otros profesionales de la comunidad.

Y si estás dando tus primeros pasos en testing, también.

Porque una de las mejores cosas de nuestra comunidad es que siempre hay alguien dispuesto a compartir lo que aprendió en el camino.

Nos vemos el 13 de octubre.

Y quizás, entre una charla y otra, podamos seguir conversando sobre esa pregunta que cada vez cobra más importancia:

¿Cómo construimos confianza en la era de la IA?

👉 Conocé la Quality Sense Conf 2026

👉 Registrate gratis acá

¿Nos vemos ahí? 😉

Si te gustan estos temas, suscríbete para recibir toda la información en tu correo!

Suscríbete ahora

“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