Curiosidades QA — Día 4 de 7 Esta semana publico una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
El dato que nadie quiere escuchar
Hay un número que incomoda a cualquier equipo de QA: entre el 30% y el 50% de los bugs en producción los detecta el usuario final. No el equipo de testing. No las pruebas automatizadas. No el code review. El usuario.
La persona que está usando tu producto a las 11 de la noche, desde un celular con poca señal, haciendo algo que a nadie se le ocurrió probar.
¿Por qué se escapan tantos bugs?
No es porque los equipos de QA sean malos. Es porque hay una brecha fundamental entre cómo probamos y cómo se usa el producto en la realidad.
1. Probamos el happy path demasiado
La mayoría de los planes de prueba dedican el 70% del esfuerzo al flujo exitoso. ¿Funciona el registro? ✅ ¿Funciona el login? ✅ ¿Funciona la compra? ✅ Aprobado.
Pero el usuario no vive en el happy path. El usuario cierra la app a mitad de una transacción. Cambia de wifi a datos móviles mientras carga una página. Tiene 47 pestañas abiertas. Usa un Android de hace 4 años con una versión del browser que nadie en tu equipo tiene instalada.
2. Probamos en condiciones ideales
Tu ambiente de staging tiene datos limpios, buena conexión, y cero concurrencia. Producción tiene datos sucios de 5 años, usuarios en zonas con 3G, y picos de tráfico impredecibles.
Un test que pasa en staging y falla en producción no es un test confiable — es una ilusión de cobertura.
3. No probamos lo que no imaginamos
Este es el más difícil. No puedes escribir un caso de prueba para algo que no se te ocurrió. Y los usuarios tienen una creatividad infinita para usar tu producto de formas que nunca contemplaste.
El dato que más duele: por cada usuario que reporta un bug, hay 26 que simplemente se van sin decir nada. Ese 40% que sí reporta es la punta del iceberg.
Los bugs que más se escapan
No todos los bugs tienen la misma probabilidad de llegar a producción. Estos son los que más se escapan según los datos de la industria:
Bugs de integración — Todo funciona aislado, pero cuando dos sistemas hablan entre sí aparece el problema. El módulo de pagos funciona. El módulo de inventario funciona. Pero cuando alguien paga y el inventario no se actualiza… ese bug lo encuentra el usuario.
Bugs de rendimiento — Tu app funciona perfecto con 10 usuarios. Con 10,000 se arrastra. Nadie probó qué pasa con carga real.
Bugs de datos reales — Tu test usa “Juan Pérez” y “test@email.com”. El usuario se llama “María José de la O’Brien-García” y su email tiene un ”+” antes del @. Tu validación explota.
Bugs de estado — Todo funciona si sigues el flujo lineal. Pero si vas atrás, recargas la página, cambias de pestaña y vuelves, el estado de la app ya no es consistente.
Lo que no puedes cambiar vs lo que sí
No puedes probar todas las combinaciones posibles. Es matemáticamente imposible. El principio 2 del ISTQB lo dice claro: las pruebas exhaustivas no existen.
Sí puedes ser más inteligente sobre dónde pones tu esfuerzo:
Mira dónde ya fallaste. ¿Dónde aparecen los bugs en producción? ¿En qué módulo? ¿En qué tipo de flujo? Los bugs se agrupan — si el 60% de tus incidentes son en el módulo de pagos, ahí es donde debería estar el 60% de tu esfuerzo de testing.
Escucha al soporte. El equipo de soporte al cliente sabe exactamente qué se rompe y cómo. Si no estás leyendo los tickets de soporte al menos una vez por semana, estás probando a ciegas.
Prueba con datos reales. No con “test123”. Con datos que se parezcan a lo que tus usuarios realmente ingresan. Con nombres largos, caracteres especiales, campos opcionales vacíos.
Haz testing exploratorio. No todo tiene que estar en un caso de prueba escrito. A veces sentarte 30 minutos a usar tu producto como un usuario real — sin plan, sin script, solo curiosidad — encuentra más bugs que una suite de 200 tests.
La reflexión
Ese 40% no es una señal de que QA está fallando. Es una señal de que la realidad siempre es más compleja que cualquier plan de pruebas.
La pregunta no es “¿cómo llego a 0 bugs en producción?” — eso es imposible. La pregunta es: “¿estoy encontrando los bugs que más importan antes de que los encuentre el usuario?”
Si la respuesta es “no sé”, tu primer paso no es escribir más tests. Es mirar los últimos 10 bugs de producción y preguntarte: ¿por qué no los encontré yo?
La respuesta a esa pregunta vale más que 100 casos de prueba nuevos.
Mañana: ¿Conoces el test que dura 0 segundos y encuentra bugs reales? → Día 5