Qué es QA

James Bach y Michael Bolton son dos de las voces más influyentes del software testing contemporáneo. Consultores, autores y formadores con décadas de experiencia, son especialmente conocidos por su trabajo en exploratory testing y por desarrollar Rapid Software Testing, un enfoque que entiende el testing menos como la ejecución mecánica de pruebas y más como una actividad intelectual de investigación, aprendizaje y evaluación.

James Bach y Michael Bolton definen testing como el proceso de evaluar un producto aprendiendo sobre él, a través de experimentarlo, explorarlo y hacer experimentos con él.

Vale la pena detenerse en dos palabras de esa definición, porque explican casi todo lo demás.

La primera es aprendiendo. Si al terminar nadie sabe nada que no supiera al empezar, no hubo testing: hubo verificación de una lista escrita de antemano. Eso también hace falta, y tiene otro nombre: checking.

Contenidos

Cuando la suite miente

Conceptos útiles

Los ABCs del Testing

El pipeline y sus etapas

Glosario

La segunda es experimentos. Un experimento tiene sentido cuando no se conoce el resultado de antemano. Ahí está la frontera completa: el testing empieza sin saber la respuesta, y el checking empieza sabiéndola.

QA es la disciplina que contiene a las dos, y que decide dónde corre cada una, quién la hace, y con qué presupuesto de tiempo. Casi todos los problemas que un equipo llama "problemas de QA" son en realidad problemas de esa decisión.

Buenas Prácticas

Salud del build: buenas prácticas de feedback rápido y visibilidad

Cuando el trabajo se acumula en QA: tres lecturas de un mismo síntoma

Diseñamos el futuro desde el pasado

Este hub dibuja 3 estados de madurez hacia un QA lo más agéntico posible:

Pre-agentic era (el ayer). Sin IA en el proceso. El costo de verificar lo ponen el tamaño de la suite y la coordinación entre personas.
Asistido por IA (madurez intermedia). Las mismas labores, las mismas fronteras de rol, el mismo flujo, con IA acelerando tareas puntuales dentro de cada labor. Sube el caudal que llega a verificación; la forma del proceso todavía no cambia.
Agéntico. Donde la pregunta ya no es qué tarea se acelera, sino si el reparto de labores y la secuencia siguen teniendo sentido, y quién declara lo que debe ser siempre verdad.

El valor de separar el 1 del 2 es evitar el error más común al hablar de esto: comparar el estado agéntico contra un "antes" que ya tenía IA adentro, y atribuirle a lo agéntico un cambio que en realidad ya había ocurrido en la fase asistida.

En QA ese error tiene una consecuencia cara y concreta:

<aside> ☝

buena parte de lo que la industria vende hoy como "QA agéntico" resuelve problemas que ya existían en el nivel 1, y varios que existían desde el nivel 0.

</aside>

Una suite lenta, un ambiente compartido por el que se pide turno y un traspaso entre quien programa y quien prueba no son problemas que trajo la IA. Son problemas que la IA hizo visibles al saturarlos.

Lo que no cambia en ninguno de los tres

Tres cosas atraviesan los tres niveles y por eso viven en páginas propias, fuera de los niveles:

La distinción entre testing y checking. No se mueve. Lo que se mueve es quién hace cada uno y qué proporción puede hacer una máquina.
Las cuatro trabas del flujo. Máquina, Persona, Intelecto y Sistema existen en los tres niveles. Lo que cambia es cuál domina.
El verde falso. Una suite que da verde sin verificar nada hace el mismo daño en cualquier nivel. Solo que a mayor madurez, más barato es producirla.