El síndrome del QA apagafuegos

Hay una escena que se repite demasiado en equipos de software.

El proyecto avanza.

Las decisiones se toman deprisa.

El desarrollo empieza con huecos.

La fecha de entrega se acerca.

Y QA aparece cuando casi todo está montado, con presión, poco contexto y muy poco margen real para prevenir.

Entonces algo falla.

Y aparece la pregunta de siempre:

“¿Por qué QA no lo vio?”

La pregunta parece técnica, pero muchas veces es organizativa.

Porque si QA llega cuando ya hay humo, no está haciendo calidad. Está haciendo emergencia.

QA no es un servicio de rescate

QA puede detectar errores.

Puede abrir tickets.

Puede priorizar riesgos.

Puede documentar evidencias.

Puede decir con claridad qué no debería llegar a producción.

Pero QA no puede viajar al pasado.

No puede compensar todas las conversaciones que no ocurrieron.

No puede arreglar un requisito ambiguo después de semanas de desarrollo sin pagar el precio.

No puede convertir una decisión tomada tarde en una prevención temprana.

Y no debería cargar con toda la culpa de un problema que nació mucho antes de la fase de pruebas.

Cuando un equipo usa QA como apagafuegos, el mensaje real es este:

la calidad importa, pero solo cuando ya duele.

El problema empieza antes del bug

Un bug no siempre nace en el código.

A veces nace en una historia de usuario escrita con prisa.

A veces nace en una regla de negocio que nadie confirmó.

A veces nace en una excepción que se dejó fuera porque parecía poco probable.

A veces nace en una reunión donde nadie preguntó lo incómodo.

A veces nace en una frase demasiado conocida:

“Eso ya se entiende.”

Y luego llega QA, prueba, encuentra el fallo y parece que el problema apareció en ese momento.

Pero no apareció ahí.

Ahí se hizo visible.

Probar tarde sale caro

Meter QA al final puede parecer rápido.

Durante un tiempo incluso parece práctico.

El equipo desarrolla sin interrupciones.

Producto avanza.

Desarrollo entrega.

La planificación se ve limpia.

Hasta que QA empieza a encontrar cosas que no son solo bugs pequeños, sino señales de que algo se pensó tarde.

Flujos incompletos.

Permisos sin definir.

Casos límite ignorados.

Mensajes que no ayudan al usuario.

Reglas que cambian según perfil, país, estado o tipo de cliente.

Y entonces corregir ya no es una conversación de diez minutos.

Es retrabajo.

Es presión.

Es negociación.

Es retraso.

Es producción esperando.

Es el cliente preguntando qué pasa.

Probar tarde no ahorra tiempo. Muchas veces solo cambia el momento en que pagas la deuda.

Un QA a tiempo hace preguntas antes del incendio

Un QA que participa desde el inicio no está ahí para frenar.

Está ahí para mirar riesgos antes de que se vuelvan caros.

Pregunta qué pasa si el usuario no tiene datos.

Pregunta quién puede ver, editar o borrar una información.

Pregunta qué ocurre si una integración falla a mitad del proceso.

Pregunta si el caso feliz representa la vida real o solo la demo.

Pregunta dónde queda escrita una decisión que acaba de cambiar.

Pregunta qué impacto tendría que esto falle en producción.

Eso también es testing.

Aunque todavía no haya entorno.

Aunque todavía no haya ticket.

Aunque todavía no exista una pantalla terminada.

Porque hacer QA no es solo ejecutar pruebas. También es leer el riesgo antes de que tenga forma de bug.

La calidad no empieza en la columna de QA

Hay equipos que hablan de calidad como si perteneciera a una fase.

Análisis.

Diseño.

Desarrollo.

QA.

Release.

Pero la calidad no vive en una columna del tablero.

Vive en cómo se decide.

En cómo se escribe.

En cómo se pregunta.

En cómo se comunica.

En cómo se prioriza.

En cómo se acepta una alerta sin convertirla en ataque personal.

Un equipo con cultura de calidad no espera a que QA confirme si algo está roto.

Construye con suficiente criterio para reducir la probabilidad de romperlo.

Culpar a QA es más fácil que mirar el sistema

Cuando algo falla al final, señalar a QA suele ser cómodo.

Es una forma rápida de buscar una persona responsable.

Pero no siempre es honesto.

Si QA no estuvo en las conversaciones iniciales, no pudo detectar ambigüedades a tiempo.

Si QA recibió la funcionalidad cuando ya no había margen, no pudo prevenir.

Si QA trabajó sin contexto, sin criterios claros y con la fecha encima, el problema no es solo QA.

Es el sistema que decidió meter la calidad demasiado tarde.

Y esa decisión tiene consecuencias.

La prevención también tiene que verse

Una de las partes más injustas del trabajo QA es que lo prevenido no siempre se nota.

El bug que nunca nació no aparece en Jira.

La incidencia que se evitó no tiene captura.

El retrabajo que no hizo falta no se celebra.

La pregunta que ahorró una semana no siempre queda registrada.

Por eso muchos equipos siguen valorando más el incendio apagado que el incendio evitado.

Pero un QA con criterio no solo aporta cuando encuentra fallos.

Aporta cuando evita que el equipo construya sobre una suposición floja.

Aporta cuando traduce una duda técnica en riesgo de negocio.

Aporta cuando cuida al usuario antes de que el usuario tenga que sufrir el error.

Si QA entra tarde, el equipo ya decidió tarde

La frase de la lámina lo resume sin maquillaje:

Si la calidad llega tarde, ya no es calidad. Es emergencia.

Y una emergencia puede resolverse.

Claro que sí.

Pero no deberíamos confundir apagar fuegos con tener una cultura de calidad.

Un QA a tiempo previene.

Un QA tarde rescata.

Las dos cosas requieren oficio.

Pero solo una cambia de verdad la forma en que el equipo construye producto.

La pregunta incómoda queda abierta:

¿En tu equipo QA previene o solo llega cuando ya hay incendio?