El testing muestra la presencia de defectos, no su ausencia

La suite de tests pasa. Verde en todas las líneas. El pipeline de CI se completa sin un solo fallo. Y entonces alguien de soporte te escribe: “Oye, un cliente dice que no puede completar el registro desde hace tres días”. Miras los tests, están todos verdes. Miras producción, el bug lleva ahí desde el último deploy. Tus tests no fallaron porque nunca estuvieron diseñados para detectar ese defecto.

Qué dice el principio

El primer principio del testing según ISTQB lo deja claro: el testing puede demostrar que existen defectos, pero no puede demostrar que no los hay. Es una distinción sutil pero fundamental. Que tus tests pasen solo significa que los escenarios que has definido funcionan como esperabas. Nada más.

La idea no es nueva. Tiene raíces en la filosofía de la ciencia, concretamente en el principio de falsabilidad de Karl Popper. De la misma forma que un solo cisne negro refuta la afirmación de que todos los cisnes son blancos, un solo bug encontrado demuestra la presencia de defectos. Pero ejecutar un millón de tests sin fallos no demuestra que el software esté libre de bugs.

Dijkstra lo resumió hace décadas de forma memorable: “El testing puede usarse para mostrar la presencia de bugs, pero nunca para mostrar su ausencia”. No era una opinión pesimista, sino una observación técnica sobre los límites inherentes de cualquier proceso de verificación.

Por qué importa en la práctica

Este principio parece teórico hasta que te golpea en producción. Hay patrones que se repiten en prácticamente todos los equipos donde he trabajado.

La falsa confianza de la suite verde

Un equipo con 2.000 tests y un 95 % de cobertura tiende a sentir que su producto está blindado. Esa sensación es peligrosa. He visto proyectos con métricas de cobertura envidiables que seguían acumulando bugs críticos porque la suite probaba muchas líneas de código pero validaba pocos comportamientos reales. La cobertura mide qué código se ejecuta durante los tests, no qué condiciones se verifican de verdad.

Cobertura alta sin asserts significativos

Este es uno de los problemas más frecuentes y más difíciles de detectar en una revisión rápida. Un test que llama a una función y comprueba que no lanza excepción técnicamente cubre esas líneas. Pero si no valida que el resultado sea correcto, que los efectos secundarios se produzcan o que el estado final sea el esperado, ese test es humo. En mi experiencia, cuando haces una auditoría seria de una suite grande, descubres que entre un 10 y un 20 % de los tests no tienen asserts significativos o validan cosas triviales como que el resultado no sea null.

El clásico “en mi máquina funciona”

Los tests pasan en el entorno de desarrollo. Pasan en CI. Pero el bug aparece en producción porque hay una diferencia en la configuración del servidor, en la versión de una dependencia transitiva, en los datos reales del usuario o en la concurrencia bajo carga. Tus tests demuestran que el código funciona en las condiciones que has definido. Producción tiene sus propias condiciones, y no siempre coinciden.

El registro que nadie probó

Imagina un formulario de registro con validación de email, contraseña y nombre. Tienes tests para email inválido, contraseña corta y campos vacíos. Todos pasan. Pero nadie escribió un test para un email con caracteres unicode válidos según el RFC pero que tu librería de validación no soporta. Nadie probó qué pasa cuando el servicio de envío de emails de confirmación tarda más de 30 segundos. Nadie simuló un registro desde un navegador con JavaScript parcialmente bloqueado. Los tests cubren lo que imaginaste, y los bugs viven donde no imaginaste.

Errores comunes al ignorar este principio

Cuando un equipo olvida que los tests solo prueban presencia de defectos, cae en trampas predecibles.

• Usar la cobertura como objetivo en lugar de como indicador. Perseguir un número de cobertura lleva a escribir tests que recorren código sin validar comportamiento. El resultado es una métrica alta y una protección baja.
• Reducir el testing exploratorio porque la suite está verde. Si los tests automatizados pasan, se asume que no hace falta explorar manualmente. Pero la suite solo prueba lo conocido. Lo desconocido necesita ojos humanos con mentalidad destructiva.
• Tomar decisiones de release basándose exclusivamente en el resultado de la suite. He visto equipos que automatizan el deploy a producción si los tests pasan, sin ninguna validación adicional. Eso funciona hasta que deja de funcionar, y cuando deja de funcionar el impacto suele ser grande.
• No cuestionar los tests que siempre pasan. Un test que no ha fallado en un año puede significar dos cosas: que el código que valida es muy estable, o que el test no es sensible a los cambios reales. La segunda opción es más común de lo que parece.

Cómo aplicarlo en tu equipo

Aceptar que los tests no garantizan ausencia de bugs no es rendirse. Es ajustar la estrategia para maximizar la detección real.

1. Incorpora mutation testing

El mutation testing es la forma más directa de saber si tus tests realmente detectan defectos. Herramientas como Stryker modifican el código de producción de formas controladas, por ejemplo cambiando un > por >=, eliminando una línea o invirtiendo un booleano, y comprueban si algún test falla. Si la mutación sobrevive, tus tests no habrían detectado ese tipo de error.

No necesitas ejecutarlo sobre todo el proyecto. Empieza por los módulos más críticos y ve ampliando. Los resultados suelen ser reveladores: suites con un 90 % de cobertura donde el 40 % de las mutaciones sobreviven.

2. Haz testing exploratorio con foco

El testing exploratorio no es “hacer clic por ahí a ver qué pasa”. Es una actividad estructurada donde defines una misión, un tiempo limitado y documentas lo que encuentras. Por ejemplo: “durante 30 minutos voy a explorar el flujo de recuperación de contraseña usando direcciones de email con caracteres especiales y conexiones lentas”.

Este tipo de testing complementa la suite automatizada porque va precisamente donde la automatización no llega: los caminos que nadie pensó en codificar.

3. Revisa la calidad de los asserts

Dedica una sesión a revisar los tests de un módulo crítico y clasifica cada assert en tres categorías. Los asserts fuertes validan comportamiento específico y fallarían si el código se comporta de forma incorrecta. Los asserts débiles validan cosas genéricas como que el resultado no sea nulo o que la respuesta tenga un status 200, sin comprobar el contenido. Y los asserts ausentes son tests que ejecutan código pero no comprueban nada significativo.

Si más de un 20 % de tus asserts son débiles o ausentes, tienes un problema de calidad de tests que la cobertura no refleja.

4. Pregúntate qué NO estás probando

Después de escribir tests para una funcionalidad, párate y hazte una pregunta incómoda: “si tuviera que encontrar un bug aquí, por dónde atacaría?” Piensa en las entradas que no has contemplado, los estados previos que no has configurado, las dependencias externas que has mockeado con respuestas felices y las condiciones de carrera que has ignorado.

En mi experiencia, los bugs más dolorosos de producción viven justo en esos huecos entre lo que probamos y lo que asumimos.

5. Diversifica las fuentes de defectos

No dependas solo de los tests automatizados. Combina varias capas de detección que se complementen entre sí.

• Tests automatizados para la regresión conocida y los happy paths.
• Testing exploratorio para descubrir lo que la automatización no cubre.
• Monitorización en producción con alertas sobre errores 5xx, latencias anómalas y tasas de error por endpoint.
• Feature flags para despliegues graduales que limiten el radio de impacto si algo falla.
• Revisión de código con foco en los caminos que no se están testeando, no solo en el estilo o la legibilidad.

Los tests son una red, no un muro

Una suite de tests es como una red de pesca. Atrapa muchas cosas, pero siempre hay peces que pasan entre los huecos. La clave no es pretender que la red es impermeable, sino saber dónde están los huecos más grandes y usar herramientas complementarias para cubrirlos.

La próxima vez que tu suite pase al 100 %, en lugar de sentir alivio, pregúntate: “qué defectos podrían estar ahí fuera y mis tests no son capaces de ver?” Esa pregunta, repetida de forma honesta, es lo que separa a un equipo que confía ciegamente en sus tests de uno que realmente protege su software.

Un ejercicio para esta semana: elige tres tests de tu módulo más crítico y analiza sus asserts. Si alguno solo comprueba que no hay excepción o que el resultado no es nulo, reescríbelo para que valide el comportamiento real. Ese pequeño cambio ya te acerca a una suite que detecta defectos de verdad.