Curiosidades QA — Día 5 de 7 Esta semana publico una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
La técnica más subestimada del testing
Hay una forma de encontrar bugs que:
- No requiere abrir la aplicación
- No requiere escribir código
- No requiere configurar un ambiente
- No requiere datos de prueba
- Toma menos de 10 minutos
Y encuentra bugs reales, no teóricos.
Se llama rubber duck testing (testing del patito de goma) y viene de una técnica que usan los desarrolladores para debuggear: explicarle el problema a un patito de goma.
Suena ridículo. Pero funciona. Y aplicado a testing, es oro puro.
Cómo funciona (en serio)
La técnica original es del libro The Pragmatic Programmer. Un programador atorado con un bug lleva un patito de goma a su escritorio y le explica el código línea por línea. En algún punto de esa explicación — normalmente antes de terminar — el programador dice “un momento…” y encuentra el bug. Sin que el patito haga nada.
La razón es que cuando tienes que verbalizar lo que hace tu código, detectas las inconsistencias que leyendo en silencio pasabas por alto.
Aplicado a testing, funciona igual. Pero en vez de código, explicas el requerimiento o el flujo en voz alta. A un colega. A un patito. A tu pared. A lo que sea que escuche.
Qué pasa cuando lo haces
Esto es lo que he encontrado haciendo rubber duck testing en proyectos reales:
Contradicciones en los criterios de aceptación “El usuario debe poder pagar con tarjeta…” (sigues leyendo) “…o con saldo interno si tiene.” Espera, ¿qué pasa si no tiene saldo? ¿Se le muestra la opción deshabilitada o no se le muestra? El criterio no lo dice. Y eso es un bug esperando a nacer.
Flujos imposibles que nadie notó Al explicar el flujo completo te das cuenta de que el paso 3 requiere información que solo se genera en el paso 5. Alguien invirtió el orden y nadie lo notó en el refinamiento.
Validaciones que se cancelan entre sí “El campo edad debe ser mayor a 18” pero “también debe aceptar el valor null si el usuario es invitado”. ¿Qué pasa con un invitado de 15 años que llena el formulario con edad real? ¿Se valida como usuario o como invitado?
Suposiciones que no están escritas Mientras explicas, te escuchas decir “claro, obviamente si el pago falla se reintenta”. ¿Obviamente? ¿Dónde dice eso? ¿Cuántas veces? ¿Con qué delay? ¿Y si el usuario ya cerró la app?
El momento mágico es cuando te escuchas decir algo como “esto debería hacer X…” y te das cuenta de que no estás seguro de si realmente hace X o tú lo estás asumiendo. Ese instante es un bug potencial documentado.
Por qué funciona (la ciencia detrás)
No es magia. Es cómo funciona tu cerebro.
Cuando lees un requerimiento en silencio, tu cerebro rellena los huecos automáticamente. Das por asumido que las cosas conectan, que los casos bordes están cubiertos, que la lógica fluye. Tu cerebro es eficiente así.
Cuando tienes que explicarlo en voz alta, ese modo de “eficiencia automática” se apaga. Tu cerebro tiene que construir cada conexión de forma explícita. Y ahí es donde los huecos se hacen visibles.
Los estudios muestran que verbalizar un problema activa áreas del cerebro diferentes a las de lectura silenciosa. Por eso los desarrolladores encuentran bugs explicándole código a un patito. Por eso los QA encontramos bugs explicando requerimientos en voz alta.
La versión QA: cómo aplicarlo
Esta es mi versión, afinada con los años:
1. Elige el requerimiento, ticket o flujo que vas a probar
2. Siéntate con alguien (o algo — un patito, tu gato, tu cámara apagada). La clave es que vas a hablar en voz alta, no pensar.
3. Explica el flujo completo desde el inicio hasta el final. Qué hace el usuario, qué responde el sistema, qué valida, qué guarda, qué muestra.
4. Cada vez que digas “obviamente”, “claramente”, “se asume que”, o “debería” — anota eso como pregunta. Son tus suposiciones ocultas.
5. Cada vez que te detengas porque “algo no cuadra” — anota eso también. Es un bug potencial.
6. Al final, convierte las anotaciones en:
- Preguntas para el PO/Dev (las suposiciones)
- Casos de prueba (los flujos que no cuadran)
- Bugs potenciales (las contradicciones)
En 10 minutos vas a tener una lista que, te apuesto, el refinamiento no produjo.
Lo que nadie te dice
Esta técnica tiene un beneficio secundario que casi nadie menciona: te hace mejor en refinamientos.
Si haces rubber duck testing regularmente, desarrollas el hábito de detectar huecos lógicos mientras escuchas. En la siguiente reunión, cuando alguien presente un requerimiento, tu cerebro ya va a estar en “modo verbalización”. Vas a hacer las preguntas incómodas que nadie más hace.
Y esa es la habilidad más valiosa de un QA senior.
La reflexión
El mejor test no siempre es el más sofisticado. A veces es el más simple: explicar en voz alta lo que dice el requerimiento, antes de escribir un solo caso de prueba.
No necesitas Playwright. No necesitas Selenium. No necesitas IA. Necesitas una silla, un tema, y 10 minutos para hablar contigo misma.
Y la primera vez que lo hagas y encuentres un bug antes de que el dev escriba código, vas a entender por qué esta técnica sobrevive décadas sin cambiar.
Mañana: ¿Sabes cuál fue el videojuego más vendido de la historia? Salió con más de 40 bugs conocidos. → Día 6