📊 statistics

An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

Este artículo propone un límite superior libre de distribución para la probabilidad de que un usuario encuentre un defecto de software no descubierto, demostrando que la fracción de defectos reportados exactamente una vez durante las pruebas beta ( $s/n$ ) sirve como una estimación conservadora e independiente del modelo adecuada para las decisiones de lanzamiento.

Autores originales: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Publicado 2026-07-21

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

La Gran Cacería de Bichos: Por qué contar bichos no es suficiente

Imagine que es un chef a punto de servir un banquete gigante a miles de invitados. Antes de abrir las puertas, tiene un equipo de catadores (sus probadores beta) que han estado comiendo la comida y gritando: "¡Oye, esta sopa está demasiado salada!" o "¡Hay una piedra en este pastel!". Usted corrige los problemas que ellos encuentran. Pero aquí surge la pregunta aterradora: Si abre las puertas ahora mismo, ¿cuáles son las probabilidades de que un invitado que entre al azar muerda una piedra que usted pasó por alto?

Este es el corazón de un problema en la informática llamado "fiabilidad del software". Durante décadas, los desarrolladores han intentado responder a esto contando. Preguntan: "¿Cuántas piedras quedan en la cocina?". Utilizan matemáticas complejas para adivinar el número total de bichos ocultos. Pero hay un truco: saber que quedan diez piedras no le dice si todas están en la parte trasera de la despensa (donde solo una persona podría encontrarlas) o si una roca gigante está situada justo en la puerta principal (donde todos tropezarán con ella). Los métodos antiguos suelen quedarse estancados intentando contar las piedras, ignorando que algunos bichos son mucho más peligrosos que otros debido a dónde están.

Para resolver esto, necesitamos dejar de contar rocas y empezar a contar personas. Necesitamos saber la probabilidad de que un usuario encuentre un problema. Este artículo aborda exactamente esa pregunta: en lugar de preguntar "¿Cuántos bichos quedan?", pregunta "¿Cuál es la probabilidad de que un usuario se encuentre con un bicho que nunca ha visto?". Resulta que hay una forma sorprendentemente simple de adivinar esto, usando un truco que observa con qué frecuencia los evaluadores encuentran el mismo bicho más de una vez.

La gran idea del artículo: La regla de la "Maravilla de una sola vez"

Los autores, Carlos M. Hernández-Suárez y Karla Hernández-Cuevas, proponen un atajo ingenioso. Sugieren que para adivinar el riesgo de que un usuario encuentre un bicho oculto, no necesita saber el número total de bichos, cómo está construido el software, ni siquiera cuántas personas lo están usando. Solo necesita mirar sus informes de errores y contar algo muy específico: los bichos que fueron reportados exactamente una vez.

Usemos una analogía. Imagine que es un detective tratando de averiguar cuántas especies diferentes de alienígenas están visitando su ciudad. Tiene un libro de registro de avistamientos.

Si ve a "Zog" 50 veces, sabe que Zog es un alienígena común.
Si ve a "Xyl" 3 veces, Xyl es un poco más raro.
Pero si ve a "Blorp" exactamente una vez, y nunca más, ¿qué le dice eso?

El artículo argumenta que estos "Blorps" —los bichos vistos exactamente una vez— son la clave. Llaman a la fracción de estos avistamientos únicos ( $s$ ) dividida por el número total de avistamientos ( $n$ ) un "límite superior conservador". En lenguaje sencillo: El porcentaje de bichos que fueron reportados exactamente una vez es una estimación segura y de "peor escenario" para el porcentaje de usuarios que encontrarán un bicho nuevo y no visto.

Por qué esto funciona (La lógica de la "Puerta Cerrada")

Usted podría preguntarse: "¿Qué pasa si hay bichos escondidos detrás de otros bichos? Como una habitación secreta detrás de una puerta cerrada". Los autores abordan esto con una lógica brillante.

Imagine que el software es una mansión gigante con muchas habitaciones. Algunos bichos están en el pasillo (fáciles de encontrar). Algunos están en una habitación secreta detrás de una puerta cerrada (difíciles de encontrar).

Si un usuario llega a la puerta cerrada (un bicho), no puede entrar en la habitación secreta que hay detrás.
Por lo tanto, el número de personas que pueden llegar a la habitación secreta es siempre menor o igual al número de personas que chocan con la puerta cerrada.

Los autores demuestran que, debido a esta estructura "anidada", no es necesario preocuparse por las habitaciones secretas. Los bichos de "reporte único" que sí encontró ya contabilizan el riesgo de los ocultos. Si un bicho se reporta una vez, actúa como una "puerta" que limita el riesgo de todo lo que hay detrás. Así que contar los reportes únicos es suficiente para cubrir toda la casa.

Lo que hicieron y lo que encontraron

Los autores no solo adivinaron; construyeron un modelo matemático llamado "Forma Canónica" (piense en ello como un tipo especial de urna o frasco lleno de bolas de colores). Demostraron matemáticamente que si trata sus informes de errores como si estuviera extrayendo bolas de este frasco, la fracción de bolas que aparecen solo una vez ( $s/n$ ) es el estimador de máxima verosimilitud exacta para la "masa faltante" (los bichos no vistos).

Crucialmente, demostraron que este estimador es conservador. Esto significa que tiende a sobreestimar el riesgo en lugar de subestimarlo.

Por qué esto es bueno: Si usted es un desarrollador decidiendo si lanzar un software, quiere estar seguro. Si las matemáticas dicen "Hay un 5% de probabilidad de un bio", y la probabilidad real es del 3%, usted está seguro. Si las matemáticas dijeran 3% y la probabilidad real fuera del 5%, estaría en problemas. Este método asegura que siempre esté en el lado seguro, inclinándose hacia la cautela.

Probaron esta idea utilizando simulaciones por computadora (creando poblaciones falsas de bichos con respuestas conocidas).

En una prueba con 20 bichos, encontraron que a medida que "probaban" más usuarios (aumentando el tamaño de la muestra de 25 a 400), su estimación ( $s/n$ ) era siempre mayor o igual al número real de bichos no vistos.
Por ejemplo, con 100 usuarios de prueba, el riesgo real no visto era 0.0059, y su estimación fue 0.0063. La estimación era ligeramente más alta (conservadora), pero nunca más baja.

Lo que esto NO es (Las reglas del juego)

El artículo es muy claro sobre lo que este método no puede hacer, y es importante entenderlo bien:

NO es para contar bichos. No le dice "Quedan 50 bichos". Le dice "Hay un 2% de probabilidad de que un usuario encuentre un bicho".
NO es para listas públicas de errores. Los autores descartan explícitamente el uso de esto en bases de datos de errores estándar (como las que hay en internet). ¿Por qué? Porque en esas listas, un bicho suele ser reportado una vez por una persona, incluso si 1,000 personas lo encontraron. El "conteo" se pierde. Para usar este método, necesita datos que digan: "Este bicho fue detectado por 50 usuarios diferentes", no solo "Este bicho fue reportado".
NO es una bola de cristal mágica para el futuro. Ofrece una instantánea del riesgo justo ahora. Si arregla los bichos y vuelve a probar, tiene que recalcular.

La conclusión

Este artículo ofrece una respuesta directa y sin rodeos para la decisión de lanzamiento. Dice: "No se preocie por cuántos bichos se esconden en la oscuridad. Solo observe cuántos bichos encontraron sus evaluadores exactamente una vez. Ese número, dividido por sus pruebas totales, es su estimación segura y de límite superior para cuántos usuarios se quedarán trabados en un bicho que usted pasó por alto".

Es una herramienta que convierte una incertidumbre compleja y aterradora en un número simple y seguro, asegurando que cuando el software se lanza, los desarrolladores tengan una visión clara y conservadora del riesgo para sus usuarios.

Resumen Técnico: Un Límite Superior de la Probabilidad de que un Usuario Encuentre un Defecto No Descubierto

Planteamiento del Problema
El artículo aborda una brecha crítica en la toma de decisiones de la gestión de lanzamientos de software: determinar la probabilidad de que un usuario de un producto lanzado encuentre un defecto que no fue descubierto durante las pruebas beta. La literatura existente se centra principalmente en estimar el número de defectos restantes (utilizando modelos de crecimiento de la fiabilidad del software o métodos de captura-recaptura) o la cobertura de clases no vistas en contextos de fuzzing. Sin embargo, estos enfoques no logran responder directamente a la pregunta del lanzamiento porque:

Los métodos basados en conteos requieren un "perfil operativo" (la distribución de cómo se usa el software en el campo) para convertir un conteo de defectos en una probabilidad de falla para el usuario. Este perfil es notoriamente difícil de estimar.
Los métodos de cobertura (por ejemplo, Good-Turing) se han aplicado al fuzzing de software, donde el "muestreador" es una máquina que genera entradas. En este contexto, la abundancia de un error refleja la aleatoriedad de la máquina, no la frecuencia con la que los usuarios humanos lo encuentran.
Complejidad estructural: El software no es una población plana y de intercambio como las especies biológicas; tiene una estructura de alcanzabilidad (árboles o DAGs) donde algunos defectos están "bloqueados" detrás de otros. Los métodos existentes no tienen en cuenta cómo esta arquitectura afecta la probabilidad de que un usuario encuentre un defecto específico oculto.

Los autores argumentan que la decisión de lanzamiento requiere una estimación directa de la masa faltante ponderada por el usuario: la probabilidad de que un usuario aleatorio ejecute un defecto no visto durante las pruebas.

Metodología
El artículo propone un estimador libre de distribución basado en la construcción de la urna canónica (Hernández-Suárez [10]), adaptada para el contexto del lanzamiento de software.

Interpretación de los Datos: Cada informe de prueba beta se trata como un muestreo de la población de usuarios, y cada defecto distinto se trata como una "clase". Los datos de entrada son el conjunto de conteos de informes para cada defecto.
La Forma Canónica: Los autores definen un modelo de población donde las clases se dividen en:
- Clases ordinarias: Defectos observados múltiples veces.
- El Reservorio (Componente de todos los diferentes): Un componente teórico que contiene un número infinito de clases con probabilidades ínfimas, de tal manera que cualquier muestreo de este produce una clase única y previamente no vista.
Estimación de Máxima Verosimilitud (MLE):
- El artículo demuestra que, bajo la forma canónica, la fracción de defectos reportados exactamente una vez ( $s/n$ ), donde $s$ es el número de elementos únicos (singletons) y $n$ es el número total de informes, es el Estimador de Máxima Verosimilitud (MLE) exacto de la proporción no vista ( $U$ ).
- Sesgo Conservador: La forma canónica asigna cada elemento único (un defecto visto exactamente una vez) al "reservorio de lo no visto" en lugar de tratarlo como una clase ordinaria rara. En consecuencia, el estimador $s/n$ sobrestima sistemáticamente la verdadera proporción no vista. Esto crea un límite superior conservador de un solo lado, que es la dirección deseada para una decisión de lanzamiento (errar hacia la precaución).
Gestión de la Arquitectura: El método es invariante a la estructura interna del software (árbol vs. DAG). Los autores argumentan que la "alcanzabilidad" de un defecto ya está codificada en los conteos de informes: un defecto detrás de una puerta cerrada es reportado por cero usuarios, mientras que un defecto en un camino común es reportado por muchos. Dado que el estimador depende únicamente de estos conteos, delimita automáticamente el riesgo de los defectos anidados y ocultos sin necesidad de modelar el grafo de alcanzabilidad.

Contribuciones Clave

Reencuadre del Estimando: El artículo cambia el enfoque de estimar un conteo de defectos residuales a estimar la probabilidad de que un usuario encuentre un defecto no visto, eliminando la necesidad de un perfil operativo.
Justificación Teórica: Proporciona una base rigurosa de MLE para el estimador $s/n$ dentro del marco de la urna canónica, demostrando que $s/n$ es el MLE exacto de la masa no vista bajo esta construcción.
Límite Superior Conservador: Establece que $s/n$ no es simplemente un estimador, sino un límite superior conservador de la masa no vista, ya que la construcción canónica fuerza a los elementos únicos a entrar en el reservorio de lo no visto, asegurando que el estimador nunca subestime el riesgo.
Invarianza Estructural: Demuestra que el estimador es robusto a la complejidad de la arquitectura del software, ya que la multiplicidad de los informes captura intrínsecamente las restricciones de alcanzabilidad.
Validación: El estimador es validado contra poblaciones sintéticas con una verdad de campo conocida, confirmando que el estimador medio cumple o supera consistentemente la masa faltante real ( $E[s/n] \geq E[U]$ ).

Resultados

Validación Sintética: Los experimentos en poblaciones sintéticas (tanto uniformes como de cola pesada) muestran que el estimador $s/n$ es preciso pero consistentemente conservador. En escenarios donde la población está casi saturada (todos los defectos encontrados), la verdadera masa faltante se acerca a cero, pero $s/n$ permanece positivo debido a la sobreatribución de los elementos únicos al reservorio de lo no visto.
Naturaleza de un Solo Lado: La probabilidad de que el estimador exceda la verdadera proporción no vista es alta (por ejemplo, de 0.89 a 1.00 en los escenarios probados), confirmando la fiabilidad del límite para decisiones que evitan el riesgo.
Requisitos de Datos: El artículo destaca que el método requiere datos a nivel de encuentro (por ejemplo, telemetría del canal beta o informes de fallos que registren cuántos usuarios se vieron afectados por cada defecto). Indica explícamente que los archivos de defectos públicos estándar no son adecuados porque típicamente registran una sola entrada por error independientemente de cuántos usuarios lo encontraron, destruyendo así los datos de multiplicidad necesarios para el estimador.

Significancia y Reivindicaciones
El artículo afirma proporcionar una respuesta directa y libre de distribución a la pregunta del lanzamiento de software. Su importancia radica en:

Cerrar la Brecha: Conecta la teoría estadística de cobertura (Good-Turing) con las restricciones prácticas del lanzamiento de software, abordando específicamente la naturaleza del riesgo "desde la perspectiva del usuario".
Eliminación de Supuestos: Elimina la necesidad de perfiles operativos, supuestos sobre el número total de defectos o modelos de la estructura interna del programa.
Apoyo a la Decisión: Ofrece una métrica conservadora y fundamentada ( $s/n$ ) que permite a los desarrolladores decidir cuándo lanzar: continuar las pruebas hasta que el límite superior de la probabilidad de encontrar un defecto no visto caiga por debajo de un umbral de riesgo tolerado.

Los autores mantienen la modestia respecto a las limitaciones del método, señalando que se aplica al estado del software en el momento del cálculo y requiere tipos específicos de datos de telemetría (a nivel de encuentro) en lugar de los registros estándar de seguimiento de errores. No pretenden resolver el problema de estimar el número total de defectos, sino la probabilidad específica de exposición del usuario a lo desconocido.