Cuando la ideología QA se vuelve tóxica: la perfección no siempre es el objetivo

Sin QA nuestros productos serían basura. Lo digo con todas las letras. El aseguramiento de la calidad ha salvado proyectos enteros, ha evitado pérdidas millonarias y ha protegido a usuarios de errores catastróficos. Respeto profundamente la labor de quienes se dedican a esto.

Pero también hay una conversación incómoda que debemos tener. En algunos entornos, cierta ideología dentro del mundo QA se vuelve tóxica. No porque la calidad sea mala, sino porque se confunde calidad con perfección absoluta. Y la perfección absoluta no existe en ingeniería.

Este artículo no es un ataque. Es una invitación a mirar críticamente nuestras propias prácticas. Hablo como alguien que ha estado en ambos lados del reporte de bugs.

¿Qué es un bug realmente?

Empecemos con una definición clara. El ISTQB, que es el estándar de referencia en pruebas de software, define un bug o defecto como una imperfección en un componente del software que puede causar que falle al cumplir un requisito.

La palabra clave aquí es requisito. Si algo no está especificado, no es un bug. Es una discusión de diseño, una mejora, una opinión.

El problema comienza cuando QA empieza a etiquetar como bug todo aquello que no le gusta personalmente. Código que podría ser más limpio pero funciona. Una interfaz que no sigue las últimas tendencias pero es usable. Un flujo que tarda 200 milisegundos más de lo ideal pero el presupuesto no permite optimizarlo.

Eso no es un bug. Eso es una preferencia.

La ideología tóxica

La ideología tóxica en QA se reconoce por estas señales.

Reportar como bug cualquier desviación de un ideal abstracto. El QA idealista imagina el software perfecto y mide el producto real contra esa imagen. Nunca gana el producto real.

Exigir que todo se arregle antes de lanzar, sin importar el costo o el plazo. El resultado son proyectos infinitos, entregas retrasadas y equipos frustrados.

Despreciar las decisiones del negocio como si fueran ignorantes. Un QA tóxico dice "esto es un bug" cuando el producto owner decidió conscientemente dejar algo así por razones de tiempo o mercado.

Negarse a priorizar. Quiere todo corregido, aunque el bug tenga impacto menor y afecte a un flujo secundario.

Un ejemplo real. Trabajé en un equipo donde un QA reportó como bug que el botón de guardar estaba a 6 píxeles de donde decía el mockup. La diferencia no afectaba la usabilidad. Ningún usuario se quejaría. Pero el QA insistió durante tres días. La corrección tomó dos minutos. El debate tomó horas. Esa energía se pudo invertir en encontrar problemas reales.

El contexto importa

No todo el software merece el mismo nivel de calidad. Un sistema de control de tráfico aéreo necesita tolerancia cero a ciertos fallos. Un juego indie en Early Access puede tener bugs visibles porque su valor está en la innovación, no en la perfección.

El presupuesto es real. Contratar más QA, automatizar todo y probar en 50 navegadores cuesta dinero. Alguien paga esa factura. Si el cliente no valora la perfección al 100%, insistir en ella es malgastar recursos.

El tipo de software define el umbral de calidad. Una red social que muestra un comentario desalineado no es un desastre. Un sistema de votación electoral que cuenta mal un voto sí lo es. El mismo equipo de QA debería aplicar estándares distintos según el dominio.

El propósito también importa. Una herramienta interna para un equipo de 10 personas no necesita el mismo nivel de pulido que un producto B2C con millones de usuarios. En el primer caso, los usuarios pueden tolerar imperfecciones. En el segundo, la experiencia pulida es parte del valor.

Como escribió Gerald Weinberg en "Quality Software Management", la calidad es valor para alguna persona. No es un atributo absoluto que vive en un vacuum. Es una relación entre el producto y quien lo usa.

El costo de la toxicidad

Cuando QA impone estándares irreales, el equipo empieza a ocultar trabajo. Los desarrolladores evitan mostrar avances hasta que están perfectos. El feedback se retrasa. La confianza se rompe.

También se genera fatiga en el propio QA. Perseguir la perfección imposible agota. Lleva al burnout. Muchos profesionales dejan el área porque sienten que nunca es suficiente.

Y el producto sufre. Los lanzamientos se demoran. Las features valiosas no llegan al usuario porque alguien insistió en pulir una esquina que nadie mira.

Cómo debería formarse un QA

La formación técnica es importante. Saber escribir casos de prueba, automatizar, entender la pirámide de pruebas. Pero eso no es suficiente.

Un QA bien formado también aprende pensamiento contextual. Entiende que el nivel de calidad aceptable cambia según el proyecto. Sabe diferenciar entre un bug real y una preferencia personal.

Aprende a comunicar. En lugar de escribir "Esto está mal", escribe "Según el requisito X, esto debería hacer Y, pero hace Z. Sin embargo, entiendo que el plazo es ajustado. ¿Cómo priorizamos?".

Aprende a negociar. No todo debe arreglarse antes del lanzamiento. Algunas cosas pueden ir a un backlog. Otras pueden documentarse como limitaciones conocidas.

Aprende a escuchar al negocio. El producto owner puede tener razones válidas para no corregir algo. Escucharlas no es rendirse. Es colaborar.

La formación debería incluir casos de estudio donde la perfección no era el objetivo. Proyectos que lanzaron con bugs menores y triunfaron. Proyectos que murieron por querer pulir demasiado.

El equilibrio

QA no es enemigo del equipo. Es parte del equipo. Su rol no es decir no. Su rol es informar, ayudar a decidir y proteger al usuario. Pero sin olvidar que el usuario prefiere una funcionalidad nueva el lunes que un botón perfectamente alineado el viernes dentro de tres meses.

La calidad no es un binario. No hay software sin bugs. Todo software tiene defectos. La pregunta no es si hay bugs, sino cuáles son aceptables en el contexto actual.

Un buen QA entiende esto. Un QA tóxico no.

Reflexión final

Valoro inmensamente el trabajo de QA. Sin ellos, este blog hablaría de software que no se puede usar. Pero parte del respeto es poder señalar cuando algo se desvía. La ideología tóxica dentro de QA es real. Ignorarla no ayuda a la profesión.

La solución no es eliminar estándares. Es incorporar el contexto en la formación. Es enseñar que la calidad es una conversación, no una dictadura. Es recordar que el software existe para resolver problemas humanos, no para cumplir checklists perfectos.

Como alguien me dijo una vez en una retrospectiva, "prefiero un producto que vuela y a veces aterriza duro a un producto que nunca despega porque el hangar estaba demasiado limpio".

Referencias

International Software Testing Qualifications Board. (2018). ISTQB Certified Tester Foundation Level Syllabus. Version 2018 v3.1.

Weinberg, G. M. (1992). Quality Software Management: Systems Thinking. Dorset House Publishing.

Kaner, C., Bach, J., & Pettichord, B. (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley.

Agile Alliance. (2020). The Agile Testing Manifesto and Principles. https://www.agilealliance.org

Böhm, B. W. (1981). Software Engineering Economics. Prentice Hall. (Para el contexto de coste-beneficio en calidad)