Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Si hay un tema que sigo viendo mal entendido en muchos equipos, incluso en personas que ya tienen tiempo trabajando en testing, es el de las pruebas exploratorias. Y lo digo porque todavía escucho frases como: “haz unas pruebas exploratorias ahí rapidito mientras llegan los test cases” o “eso es probar sin estructura, ¿no?”. Cada vez que escucho algo así, siento que seguimos arrastrando una idea muy limitada de lo que realmente significa explorar un sistema. Durante años se ha construido una percepción peligrosa alrededor de este tipo de pruebas. Mucha gente las ve como algo…

Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Me hace muy feliz saber que este contenido lo están leyendo personas de distintos países, porque al final todos compartimos algo en común: trabajamos en una industria donde la calidad sigue siendo uno de los temas más mal entendidos. ¿Por qué siempre que hay un problema pensamos primero en QA? Déjame comenzar con una escena que probablemente ya viviste: algo falla en producción, el equipo no tiene claridad inmediata de lo que ocurrió, el cliente comienza a reportar el problema y desde negocio aparece la presión por entender qué pasó. Y casi automáticamente surge la pregunta:…

Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Siguiendo con esta seria de blogs inspirados en el libro “How Google Tests Software”, déjame hacerte una pregunta sencilla. ¿Cuánto tarda tu pipeline en ejecutarse? 5 minutos… 15 minutos… ¿30 minutos o más? Ahora otra pregunta un poco más incómoda: ¿Cuántas veces alguien en tu equipo dice algo como esto? “Mejor no corras todo el pipeline porque tarda demasiado.” Si esto pasa en tu equipo, es muy probable hayan espacios de mejora en cómo están distribuidas las pruebas dentro del pipeline. Pero antes de hablar de eso, primero vamos a aclarar algo importante. Porque muchas personas…

Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Si llevas algunos años en tecnología, probablemente aprendiste testing con esta clasificación: unit tests, integration tests y system tests. Es casi dogma. Lo repetimos en entrevistas, en cursos, en certificaciones. He conocido muchos desarrolladores que estas palabras les producen migraña. Y sabias que probablemente tengas eso en común con los desarrolladores de Google. ¿No me crees? Pues en este blog te voy a decir por qué hace mucho que Google no organiza sus pruebas así. Y esto no me lo estoy sacando de la IA, sino del libro “How Google Tests Software”, que es el libro…

Hola mi estimado colega del mundo de desarrollo, hoy quiero decirte por qué la calidad no es un gasto, sino la forma más efectiva de ahorrar en desarrollo, y te lo quiero explicar rapidamente en este post. Durante años, muchas empresas han cometido el mismo error conceptual: confundir testing con calidad, y ese error no es inocente, cuesta dinero, mucho dinero. En el post anterior hablaba de por qué no siempre contratar más testers es la solución cuando el producto crece. Ese artículo generó bastante conversación porque toca un punto sensible: la tendencia de resolver problemas estructurales agregando más personas al final del proceso. Pero hoy quiero ir más profundo,…

Hola mi amigo de la calidad, hoy quiero comentarte que hay una frase que suena provocadora, incluso irresponsable, cuando se escucha por primera vez: “No contrates demasiados testers.” En una industria donde los productos crecen sin pausa, donde cada sprint agrega nuevas funcionalidades y donde los errores parecen inevitables, la reacción natural suele ser exactamente la contraria: más features implican más pruebas, y más pruebas implican más personas dedicadas a probar. Es una lógica que parece impecable. Sin embargo, lo que parece lógico no siempre es lo que realmente escala. El software, por definición, nunca estará libre de errores. Pensar en un sistema completamente perfecto es una falacia que cualquier…

Hubo una época en que el éxito de un equipo de QA se medía por la cantidad de test cases escritos. Si tu Excel tenía 300 filas, ibas bien. Si tenía 800, eras el rey del waterfall. Y sí, en el enfoque tradicional, predictivo, basado en proyectos tipo Waterfall, esa era la lógica: más documentación = más control = más seguridad. Pero hoy el mundo del software se mueve a otra velocidad. Y con él, la forma de entender la calidad. El modelo Waterfall y su obsesión con lo predecible Waterfall funcionaba como una fábrica: había que definir todo antes de construir, luego ejecutar paso a paso. En ese mundo,…

Hola mis estimados amigos y amigas de la calidad. Hoy quiero hablar de un tema que suele generar opiniones encontradas, especialmente entre quienes están empezando en QA, el Behaviour Driven Development, o BDD para los panas. Para algunos es una práctica poderosa que mejora la comunicación del equipo; para otros, una capa innecesaria de texto que nadie lee. La realidad es que ambas posturas pueden ser correctas, dependiendo de cómo y por qué se esté usando. BDD fue propuesto por Dan North, y originalmente ni siquiera se llamaba así. Su nombre inicial fue Behavioral Specification. La idea no era escribir casos de prueba ni documentar escenarios técnicos, sino describir el…

En más de una ocasión he visto equipos construir productos técnicamente impecables que, aun así, no logran despegar. No fallan por errores críticos, ni por una mala arquitectura, ni por decisiones técnicas deficientes. Fallan porque, simplemente, nadie los necesita o nadie los quiere usar. Esta es una realidad incómoda, pero frecuente, y tiene mucho que ver con cómo entendemos la calidad dentro de los equipos de software. Entré a uno de esos equipos hace algunos años y trabajé con ellos durante aproximadamente un año y medio. Desde el primer día quedé impresionado. La arquitectura estaba bien pensada, los patrones eran claros, el foco en performance era evidente y las decisiones…