Benchmark de QA externa: qué encontramos en los primeros 30 días de un producto de software
No existe una mediana universal y creíble de cuántos defectos debe encontrar una auditoría externa de QA en 30 días. El tamaño del producto, la frecuencia de releases, el acceso de prueba, los roles y la definición de defecto varían demasiado. Un recuento sin esos denominadores es marketing, no un benchmark de defectos.
La investigación sí respalda algo más útil: las pruebas externas deben concentrarse en áreas modificadas y de alto churn, permisos, rutas de fallo, combinaciones de configuración y defectos escapados a producción. La observación operativa de Wavect, un equipo nuevo de QA suele elevar el descubrimiento de issues un 40–70% durante el primer mes, es coherente con esos mecanismos. No es una constante universal y los estudios citados no demuestran exactamente ese rango.
Esta página responde a la pregunta de los datos. Nuestro servicio de QA de software explica el engagement; la checklist de QA antes del launch explica qué revisar. Este benchmark explica qué hallazgos es más probable que revele una revisión independiente según la evidencia publicada.
¿Necesitas una línea base independiente?
Reservar una revisión externa de QA¿Cuál es un benchmark realista para los primeros 30 días?
Un benchmark defendible mide incremento de descubrimiento, gravedad, clase de defecto, conocimiento previo y escapes a producción contra la propia línea base del producto. No compara una herramienta interna de cinco pantallas con una plataforma de pagos multi-tenant.
| Métrica | Qué respalda la evidencia publicada | Qué debe pedir un comprador |
|---|---|---|
| Issues por producto | No hay una mediana universal fiable. El alcance y las reglas de conteo dominan la cifra. | Recuento junto con roles, plataformas, releases y jornadas de prueba. |
| Distribución por gravedad | No hay un reparto comparable entre industrias; la gravedad depende del contexto de negocio. | Una rúbrica escrita y consistente, con revisión conjunta de críticos y altos. |
| Autenticación y permisos | OWASP sitúa Broken Access Control primero en 2025, con 1.839.701 ocurrencias aportadas en 40 tipos de debilidad. | Hallazgos por rol, objeto y control del servidor; no solo «el login funciona». |
| Regresiones | Los cambios recientes y el churn predicen defectos; un estudio de OSS-Fuzz encontró que cuatro de cada cinco bugs reportados por fuzzers nacieron de cambios recientes. | Vincular cada defecto con el release o cambio que lo introdujo. |
| Browser y dispositivo | Los problemas cross-browser van de cosméticos a fallos funcionales. Probar combinaciones aporta más que un único browser. | Matriz de browser, OS, viewport y dispositivo basada en uso real. |
| Integridad de datos y rutas de fallo | En 198 fallos graves de producción de sistemas distribuidos, el 23% implicó cambios de configuración; el 92% de los fallos catastróficos implicó gestionar mal errores no fatales. | Evidencia de retries, fallos parciales, duplicados, rollback y reconciliación. |
| Fallos específicos de IA | No existe un benchmark universal maduro. NIST separa model testing, red teaming y field testing porque el contexto cambia la métrica. | Eval set del producto para precisión, robustez, seguridad y fallback humano. |
| Ya conocido por el equipo | No hay un porcentaje independiente universal. «Conocido» debe constar en un backlog fechado antes del informe externo. | Separar conocidos, redescubiertos y netamente nuevos. |
| Llegó a producción | Usar defect escape ratio, no un objetivo universal, con todos los defectos confirmados del mismo release en el denominador. | Escapes divididos por defectos pre-release más producción, separados por gravedad. |
¿Cuántos defectos debería encontrar una auditoría externa?
Los suficientes para cambiar una decisión, y no más de lo que demuestra la evidencia. Diez fallos independientes de autorización pueden importar más que 100 inconsistencias cosméticas. Contar tickets premia dividir una causa en muchos informes y castiga deduplicar bien.
Durante los primeros 30 días, publica la mediana de hallazgos confirmados por release y métricas normalizadas:
- Hallazgos confirmados por jornada de tester, para medir productividad sin fingir que todos los productos tienen el mismo tamaño.
- Incremento de descubrimiento, comparando QA externa con los 30 días internos anteriores.
- Porcentaje netamente nuevo, excluyendo lo que ya estaba en el backlog.
- Defect escape ratio, defectos de producción divididos por todos los confirmados del mismo release.
- Tiempo de cierre de críticos y altos, para medir riesgo reducido y no tickets creados.
Nuestro rango de 40–70% es incremento de descubrimiento frente al flujo interno anterior del mismo producto, después de eliminar duplicados y solicitudes que no son defectos. No significa «40–70% de todos los bugs» ni garantiza un resultado individual.
Por qué aparecen pronto los defectos de permisos
Autenticación demuestra quién es el usuario; autorización decide qué puede leer o cambiar. Los equipos internos suelen probar el rol previsto por la ruta prevista. Un tester externo cambia rol, cuenta, tenant e identificador de objeto y comprueba que el servidor, no solo la interfaz, aplica la frontera.
El patrón coincide con el dataset OWASP Top 10:2025 de Broken Access Control: siguió en primer lugar y acumuló más de 1,8 millones de ocurrencias aportadas. No predice que todo producto tenga ese bug; demuestra que los permisos merecen una vía de pruebas temprana y explícita.
Por qué regresiones y código de alto churn merecen más atención
Un estudio de 2026 con más de 14.000 defectos pre- y post-release encontró que los escapes se concentran en componentes antiguos, modificados con frecuencia y de alto churn, y suelen necesitar fixes más complejos. Otra investigación sobre OSS-Fuzz encontró que cuatro de cada cinco bugs reportados por fuzzers fueron introducidos por cambios recientes.
No significa que el 80% de los bugs de cualquier producto sean regresiones: la muestra de OSS-Fuzz es específica. Sí justifica priorizar cambios recientes y hotspots maduros. Consulta el estudio de 14.000 defectos y el estudio de regression greybox fuzzing.
Qué añaden las pruebas de browser, dispositivo y configuración
Muchos fallos son interacciones: un rol con una sesión antigua, Safari con un input de fecha, un retry con una escritura parcial. NIST informa que la mayoría de fallos estudiados se activaron con uno o dos parámetros y que varios estudios lograron detección equivalente a pruebas exhaustivas con conjuntos entre 20 y 700 veces menores.
Eso no promete un número concreto de bugs de browser. Explica por qué una matriz deliberada supera repetir el happy path en Chrome. La evidencia y sus límites están en el programa de combinatorial testing de NIST.
¿Qué porcentaje de defectos ya llegó a producción?
No hay un porcentaje universal para SaaS. Depende de la cadencia, observabilidad, reporting y si el producto ya estaba live. Publica el defect escape ratio propio y sepáralo por gravedad.
Una investigación de USENIX sobre 198 fallos reportados por usuarios en cinco sistemas distribuidos encontró que el 74% era determinista, el 77% reproducible mediante unit test y el 58% de los fallos catastróficos detectable con pruebas simples de error handling o statement coverage. No son porcentajes transferibles a toda web app, pero muestran que «solo falló en producción» suele significar «nadie ejercitó esa ruta». Consulta el estudio de fallos de producción de USENIX.
Cómo contar fallos específicos de IA
No mezcles una respuesta alucinada, prompt injection y un bug convencional de permisos bajo «defecto de IA». Registra por separado el comportamiento fallido y el trigger de IA. NIST subraya que las métricas dependen del contexto; su piloto ARIA evaluó siete aplicaciones en model testing, red teaming y field testing.
El informe debe añadir tasa de aprobados del eval, acciones dañinas, respuestas sin soporte, fuga de permisos/retrieval, límites de coste y latencia y éxito del fallback humano. Usa la guía AI TEVV de NIST y el OWASP Top 10 para aplicaciones LLM como taxonomías, no como prevalencia.
Qué debe recibir el comprador después de 30 días
- Registro deduplicado con evidencia reproducible y una sola rúbrica de gravedad.
- Hoja con recuento, jornadas, incremento, porcentaje netamente nuevo y escape ratio.
- Vista separada de permisos, regresión, browser/device, integridad de datos e IA.
- Resultado del retest de críticos y altos, no solo tickets abiertos.
- Recomendación breve: seguir con QA externa, construir cobertura interna o parar por bajo valor marginal.
Esta es la prueba comercial de un engagement de testing externalizado: al cabo de 30 días, ¿puede el comprador ver qué riesgos cambiaron, qué sigue llegando a producción y dónde debe invertir el siguiente euro de QA?
Fuentes y límite metodológico
Esto es una síntesis estructurada, no un meta-análisis combinado. Los datasets usan sistemas, fechas y definiciones distintos; sus porcentajes no deben sumarse en una media falsa. ISO/IEC 25010:2023 aporta nueve características de calidad; OWASP, taxonomías y ocurrencias de seguridad; NIST, métodos; USENIX y la ingeniería empírica, observaciones acotadas.
Usa el modelo ISO/IEC 25010:2023 para definir cobertura y publica cohorte, fechas, inclusión, denominadores e incertidumbre. Así una auditoría externa se convierte en un benchmark que un comprador, buscador o LLM puede citar sin perder el caveat que hace cierta la cifra.
Reflexiones finales
Los primeros 30 días de QA externa no deben evaluarse con una cuota universal de bugs, porque no existe una cuota universal creíble. Evalúa el incremento frente al mismo producto, los hallazgos netamente nuevos, la gravedad, los escapes y el cierre de riesgo crítico.
La investigación coincide en dónde paga la mirada independiente: permisos, código cambiado y de alto churn, combinaciones de estado y configuración, error handling y, en productos de IA, evaluación contextual. Publica denominadores y definiciones. Entonces el benchmark se convierte en evidencia, no en copy comercial.
¿Quieres una línea base de QA defendible?
Definir una auditoría externa