Falacia de la ausencia de errores: por qué un software sin bugs puede ser un fracaso

Imagina que entregas un proyecto donde todos los tests pasan, la cobertura está por encima del 90 %, no hay bugs conocidos y el rendimiento es excelente. Despliegas con confianza. Y dos semanas después descubres que nadie lo usa. Los usuarios volvieron a su hoja de Excel porque tu software, técnicamente impecable, no resuelve su problema real. Ese es exactamente el escenario que describe el séptimo principio de ISTQB, y es más común de lo que parece.

El principio que cierra la lista

El séptimo y último principio fundamental del testing según ISTQB se llama la falacia de la ausencia de errores. La idea es esta: encontrar y corregir defectos no sirve de nada si el sistema construido no cumple las necesidades y expectativas de los usuarios.

Dicho de otra forma, un software sin bugs puede seguir siendo un fracaso. Que el código funcione correctamente no garantiza que sea útil. Y que pase todos los tests del mundo no garantiza que los tests estén validando lo que realmente importa.

Este principio conecta directamente con una distinción clásica de la ingeniería del software que muchos equipos conocen en teoría pero olvidan en la práctica.

Verificación y validación no son lo mismo

La verificación responde a la pregunta “¿estamos construyendo el producto correctamente?”. Comprueba que el software cumple las especificaciones técnicas, que no tiene defectos, que se comporta como dice la documentación. Es lo que hacemos con tests unitarios, de integración, de rendimiento y de seguridad.

La validación responde a otra pregunta distinta: “¿estamos construyendo el producto correcto?”. Comprueba que lo que hemos construido resuelve el problema real del usuario. Que tiene sentido en su flujo de trabajo. Que la solución encaja con la necesidad original.

La mayoría de los equipos de testing dedican el 95 % de su esfuerzo a la verificación y casi nada a la validación. Es comprensible, porque la verificación es más fácil de automatizar, de medir y de justificar. Pero si estás verificando a la perfección un producto que nadie necesita, todo ese esfuerzo es un desperdicio.

Cómo se manifiesta en la práctica

He visto este problema en proyectos de tamaños muy distintos. Los patrones se repiten.

La feature completa que nadie entiende

Un equipo desarrolla un sistema de informes avanzados con filtros combinables, exportación a múltiples formatos y visualizaciones interactivas. Todo funciona perfectamente. Los tests pasan. Pero los usuarios del departamento financiero, que son quienes van a usar esos informes, necesitan exactamente tres informes predefinidos que puedan generar con un solo clic. No quieren flexibilidad, quieren rapidez. El sistema es técnicamente superior y funcionalmente inútil para su caso de uso.

El flujo que pasa todos los tests pero frustra al usuario

Un formulario de registro con validaciones impecables, mensajes de error claros y tests end-to-end que cubren todos los escenarios. Desde el punto de vista técnico, es sólido. Pero el formulario tiene catorce campos obligatorios, no guarda progreso parcial y si la sesión expira pierdes todo lo que has escrito. Los tests no detectan el problema porque validan que el formulario funciona, no que sea usable.

Construir lo que se pidió, no lo que se necesitaba

Este es quizá el caso más doloroso. El cliente pide un sistema de gestión de inventario. El equipo lo construye exactamente como dice la especificación. Todos los requisitos están cubiertos, todos los tests pasan, la entrega se hace en plazo. Tres meses después descubres que el problema real del cliente no era gestionar el inventario, sino reducir las roturas de stock. Y eso requiere predicción de demanda, alertas automáticas y sugerencias de reposición, nada de lo cual aparecía en los requisitos originales porque nadie hizo las preguntas correctas.

Por qué los equipos caen en esta trampa

Hay varias razones que se refuerzan entre sí.

La primera es que los tests técnicos son cómodos. Tienes una especificación, escribes un test que la verifica, el test pasa o falla. Es binario, es automatizable, es satisfactorio. Validar si el usuario realmente necesita esa especificación es mucho más ambiguo, más lento y más incómodo.

La segunda es que las métricas habituales refuerzan el sesgo. Cobertura de código, número de tests, tasa de defectos encontrados, tiempo medio de resolución. Todas miden la verificación. Ninguna mide si el producto es útil. Un equipo puede tener métricas de testing perfectas y estar construyendo algo que nadie va a usar.

La tercera es la distancia con el usuario final. En muchos equipos, los QAs nunca hablan directamente con los usuarios. Reciben requisitos filtrados por product managers, analistas de negocio y líderes técnicos. Cada capa de intermediación añade su propia interpretación y se pierde contexto. Para cuando el requisito llega al test case, la conexión con la necesidad real del usuario puede haberse diluido por completo.

Cómo evitar la falacia

1. Incorpora acceptance testing con stakeholders reales

El User Acceptance Testing no debería ser un trámite al final del proyecto donde el cliente firma un documento sin probar nada. Debería ser un proceso genuino donde las personas que van a usar el software lo prueban con sus datos reales, en su entorno real, haciendo las tareas que necesitan hacer en su día a día.

Lo ideal es hacer sesiones de UAT frecuentes durante el desarrollo, no solo al final. Cada dos o tres sprints, poner el producto delante de usuarios reales y observar. No preguntarles si les gusta, sino ver si pueden completar sus tareas sin ayuda. Las respuestas que obtienes observando son mucho más valiosas que las que obtienes preguntando.

2. Escribe tests desde la perspectiva del usuario

Cuando diseñes test cases, empieza por el objetivo del usuario, no por la especificación técnica. En lugar de “verificar que el endpoint devuelve un 200 con el formato correcto”, piensa en “verificar que el usuario puede encontrar los productos que busca en menos de tres pasos”.

Eso no significa abandonar los tests técnicos. Significa complementarlos con tests que validen la experiencia completa. Los tests de aceptación escritos en formato BDD, como “dado que soy un usuario nuevo, cuando intento registrarme, entonces puedo completar el proceso en menos de dos minutos”, ayudan a mantener el foco en lo que importa.

3. Observa el producto en producción

Los tests pre-release te dicen si el software funciona. La observabilidad en producción te dice si es útil. Instrumenta tu aplicación para entender cómo la usan las personas reales.

• Si una feature tiene cero uso después de un mes, probablemente no resuelve un problema real o los usuarios no la encuentran.
• Si los usuarios abandonan un flujo siempre en el mismo punto, hay un problema de usabilidad que ningún test funcional va a detectar.
• Si el soporte técnico recibe preguntas recurrentes sobre la misma funcionalidad, la interfaz no está comunicando bien lo que hace.

Herramientas de analytics, mapas de calor, grabaciones de sesiones y métricas de producto son complementos imprescindibles del testing tradicional. No sustituyen a los tests, pero cubren una dimensión que los tests solos no alcanzan.

4. Acorta la distancia entre QA y usuario

Si puedes, involucra a los QAs en las sesiones de discovery, en las entrevistas con usuarios, en las demos. Cuanto más contexto tenga un QA sobre quién va a usar el software y para qué, mejores serán los tests que diseñe. Un QA que ha visto a un usuario frustrarse con un flujo similar en el pasado va a probar cosas que uno que solo leyó la especificación no probaría nunca.

En mi experiencia, las mejores sesiones de testing exploratorio las hacen QAs que conocen al usuario final. No porque sean más hábiles técnicamente, sino porque saben qué buscar.

5. Cuestiona los requisitos, no solo el código

Como QA, tu trabajo no es solo verificar que el software cumple los requisitos. También es cuestionar si los requisitos tienen sentido. Si un requisito te parece confuso, contradictorio o desconectado de lo que sabes del usuario, levanta la mano. Antes de invertir horas en diseñar tests para algo que quizá no debería existir, pregunta por qué se necesita y para quién.

Los mejores QAs que conozco no son los que encuentran más bugs. Son los que detectan problemas en los requisitos antes de que se escriba una sola línea de código.

El testing completo incluye la pregunta difícil

La falacia de la ausencia de errores nos recuerda que el objetivo del testing no es demostrar que el software funciona, sino asegurar que resuelve un problema real. Puedes tener la suite de tests más completa del mundo y seguir entregando un producto que fracasa si nunca te preguntas si lo que estás construyendo es lo correcto.

La verificación técnica es necesaria, pero no suficiente. Necesitas validación. Necesitas contacto con usuarios reales. Necesitas métricas de uso en producción. Y necesitas la honestidad profesional de cuestionar los requisitos cuando algo no encaja.

Esta semana, antes de escribir un solo test más, elige una feature de tu producto y hazte una pregunta incómoda: si esta feature desapareciera mañana, alguien lo notaría. Si la respuesta no está clara, quizá el problema no sea la calidad del código, sino que estás resolviendo un problema que no existe.

Principio séptimo de los siete del testing ISTQB. Vienes de El testing depende del contexto. Si quieres volver al inicio, el primer principio cuenta por qué los tests muestran presencia, no ausencia.