El bug que todos vieron, pero nadie reportó

Hay bugs que nadie reporta porque ya forman parte del paisaje.

Están ahí desde hace meses.

Todo el mundo los ha visto.

Todo el mundo sabe que existen.

Pero nadie los abre como incidencia porque aparece una frase muy conocida:

“Eso ya venía así.”

Y esa frase parece inocente.

Parece una explicación rápida.

Parece una forma de cerrar la conversación sin perder tiempo.

Pero en QA esa frase debería encender una alerta.

Porque cuando un fallo se normaliza, deja de parecer fallo. Se vuelve costumbre. Se vuelve comportamiento esperado. Se vuelve una deuda silenciosa que nadie quiere tocar.

Hasta que un usuario se queja.

Hasta que afecta al negocio.

Hasta que alguien nuevo entra al producto y pregunta lo obvio:

“¿Por qué esto funciona así?”

El bug no desaparece porque el equipo se acostumbre

Una cosa es que el equipo conozca un fallo.

Otra muy distinta es que el fallo esté controlado, documentado, priorizado y aceptado con criterio.

Muchas veces se confunden esas dos cosas.

El equipo sabe que ocurre.

Producto sabe que está ahí.

Desarrollo sabe que no quedó del todo bien.

QA lo ha visto más de una vez.

Soporte quizá ya tiene una respuesta preparada para cuando el usuario pregunta.

Y aun así nadie lo reporta.

No porque no importe.

Sino porque lleva demasiado tiempo ahí.

Ese es el riesgo: el bug deja de sentirse urgente porque ya no sorprende.

Pero que algo no sorprenda no significa que esté bien.

Las frases peligrosas

Hay frases que parecen pequeñas, pero dicen mucho de la cultura de calidad de un equipo.

“Eso ya venía así.”

Como si la antigüedad fuera una garantía.

“No rompe nada grave.”

Como si solo los errores grandes merecieran atención.

“El usuario ya se acostumbró.”

Como si acostumbrar al usuario a una mala experiencia fuera una solución.

“Siempre ha funcionado así.”

Como si repetir un comportamiento raro durante meses lo convirtiera en correcto.

Estas frases no siempre nacen de la mala intención.

A veces nacen del cansancio.

A veces nacen de una planificación llena de urgencias.

A veces nacen de un backlog que nadie consigue bajar.

A veces nacen de equipos que ya no tienen margen para mirar el producto con calma.

Pero aunque el origen sea comprensible, el efecto sigue siendo el mismo: el fallo se queda.

Lo que el equipo deja de mirar

Un producto no solo se rompe cuando aparece un error nuevo.

También se rompe cuando el equipo deja de cuestionar lo que ya sabe que no funciona bien.

Un botón que confunde.

Un mensaje que no ayuda.

Un permiso que se comporta distinto según el perfil sin que nadie recuerde por qué.

Un flujo que obliga al usuario a dar tres vueltas para hacer algo simple.

Una validación que falla de una forma rara, pero solo en algunos casos.

Una pantalla que todos evitan probar porque siempre trae problemas.

Nada de eso parece una catástrofe por separado.

Pero junto construye una experiencia frágil.

Y la fragilidad también es un riesgo de calidad.

Un QA senior no solo mira lo nuevo

Hay una idea peligrosa en algunos equipos: QA solo tiene que probar lo que acaba de cambiar.

Claro que lo nuevo importa.

Pero un buen QA también mira alrededor.

Mira qué toca esa funcionalidad.

Mira qué comportamiento antiguo se está arrastrando.

Mira qué patrón raro se repite.

Mira qué parte del producto parece aceptada solo porque nadie quiere abrir esa conversación.

Ahí se nota el criterio.

No en reportar por reportar.

Sino en saber distinguir entre una rareza tolerable y una deuda que ya está afectando al producto.

Un QA senior detecta patrones raros que otros normalizan.

Detecta riesgos para negocio, usuario y reputación.

Detecta señales pequeñas antes de que se conviertan en un problema grande.

Y a veces su aportación no empieza con:

“Esto está roto.”

Empieza con:

“Esto lleva roto tanto tiempo que ya nadie lo cuestiona.”

Normalizar un fallo también es una decisión

No todos los bugs se corrigen al momento.

Eso es real.

Hay prioridades.

Hay fechas.

Hay impacto.

Hay deuda técnica.

Hay decisiones de negocio.

Pero dejar un bug sin reportar no es lo mismo que decidir conscientemente no corregirlo ahora.

Cuando un fallo está reportado, el equipo puede medirlo.

Puede priorizarlo.

Puede explicarlo.

Puede asumirlo con contexto.

Puede volver a mirarlo cuando cambian las condiciones.

Cuando un fallo no está reportado, queda en tierra de nadie.

Existe, pero no existe.

Todo el mundo lo sabe, pero nadie lo sostiene.

Y así se queda meses dentro del producto.

El usuario no tiene por qué heredar nuestras costumbres

Desde dentro, un fallo antiguo puede parecer menor.

El equipo ya sabe cómo rodearlo.

Ya sabe dónde no tocar.

Ya sabe qué explicación dar.

Ya sabe qué camino evitar.

Pero el usuario no vive dentro del equipo.

El usuario llega con una expectativa simple: que el producto tenga sentido.

No sabe qué bug es viejo.

No sabe qué decisión se tomó con prisa.

No sabe qué parte del flujo “siempre fue así”.

Solo siente que algo no encaja.

Y esa fricción también cuenta.

Aunque no bloquee una compra.

Aunque no tire una pantalla.

Aunque no genere una alerta técnica.

Cuenta porque desgasta la confianza.

Confesión incómoda

Que un bug exista desde hace meses no lo convierte en aceptable.

Solo demuestra que nadie quiso cuestionarlo a tiempo.

Y esto no va de abrir tickets por deporte.

Va de cuidar el criterio.

Va de no confundir costumbre con calidad.

Va de mirar el producto como lo miraría alguien que no conoce nuestras excusas internas.

Porque el buen QA no solo reporta fallos.

También detecta lo que el equipo ya dejó de ver.

La pregunta queda abierta:

¿Has visto bugs que ya eran parte del paisaje?