La intuición QA existe, aunque a veces nadie quiera escucharla

Hoy mientras trabajaba lo dije al equipo de DEV con una seguridad que casi me dio risa:

“Estoy segura de que va a funcionar, porque mi intuición QA no falla.”

Y también dije la otra parte, la más peligrosa:

“Si te digo que va a fallar, falla. Y si te digo que está fixed, lo estará.”

Sé que suena exagerado.

Pero quien trabaja en QA sabe que hay momentos en los que algo dentro de ti se activa antes de tener una prueba concreta.

Ves una pantalla.

Lees una historia.

Pruebas un flujo.

Todo parece pasar.

Y aun así algo no encaja.

La intuición QA no sale de la nada

La intuición QA no es una corazonada bonita para ganar una discusión.

Es memoria.

Es haber visto el mismo patrón romperse con otro nombre.

Es recordar aquel bug que parecía pequeño y terminó bloqueando a medio equipo.

Es mirar una funcionalidad y pensar: aquí falta un caso, aquí alguien asumió demasiado, aquí el usuario no va a hacer lo que el equipo cree que va a hacer.

Por eso a veces una QA dice “esto va a fallar” antes de poder explicarlo con una evidencia perfecta.

No porque quiera frenar.

Porque ya reconoció el olor del riesgo.

Lo difícil es que te crean antes del bug

Hay una parte muy incómoda de este oficio: muchas veces la mirada QA se valora cuando el fallo ya apareció.

Antes del bug, pareces intensa.

Después del bug, pareces adivina.

Y no. No era adivinación.

Era experiencia hablando bajito.

Era criterio pidiendo una revisión más.

Era el producto avisando por una esquina que algo no estaba cerrado.

El problema es que algunos equipos solo creen en QA cuando QA trae una captura, un ticket, un vídeo y una reproducción exacta del error.

Pero el valor de QA también está antes de todo eso.

Está en detectar señales.

Está en hacer preguntas.

Está en decir “revisemos esto” cuando todavía hay tiempo.

Cuando algo está fixed, también se nota

La intuición QA no solo aparece para decir que algo va a fallar.

También aparece cuando un fix, por fin, se siente bien.

Cuando pruebas el flujo y ya no hay esa fricción rara.

Cuando el comportamiento tiene sentido.

Cuando el usuario puede avanzar sin tener que perdonar al producto.

Cuando la solución no solo pasa el caso, sino que respeta la lógica del negocio.

Ahí también habla la mirada QA.

Porque hacer QA no es buscar defectos por deporte.

Es entender cuándo algo está realmente listo.

A veces el bug aparece porque alguien decidió no escuchar

Lo he pensado muchas veces.

A veces el bug no aparece porque una QA sea adivina.

Aparece porque alguien tuvo una señal delante y prefirió seguir.

Porque la historia estaba verde.

Porque el contexto era pobre.

Porque había prisa.

Porque una pregunta incómoda se dejó para después.

Porque se confundió “funciona en mi caso” con “funciona para el producto”.

Y ahí es donde QA tiene que sostener una frase que no siempre cae bien:

que algo pase no significa que esté bien probado.

La pregunta que dejo abierta

Me interesa mucho esta conversación porque casi todas las personas QA tienen una historia así.

Un momento en el que vieron venir el fallo.

Un “esto huele raro”.

Un “aquí falta algo”.

Un “yo no lo subiría todavía”.

Un “si esto llega a producción, vuelve”.

Y luego volvió.

Así que lo dejo aquí, en modo confesionario:

¿Alguna vez tu intuición QA vio venir un bug antes que el resto del equipo?

Completa la frase:

“Yo sabía que iba a fallar cuando…”