Una falla, defecto u omisión en requisitos, diseño, código, configuración o integración de software que puede provocar comportamientos del sistema incorrectos, inesperados o inseguros cuando se ejercitan bajo entradas, estados, temporizaciones o condiciones ambientales particulares.

Principio

Existe un defecto cuando hay una discrepancia entre el comportamiento previsto y el implementado para un contexto especificado; los defectos surgen de requisitos incompletos o ambiguos, algoritmos incorrectos, errores de programación, incompatibilidades de interfaz o suposiciones dependientes del entorno y sólo se manifiestan cuando ocurren las condiciones desencadenantes.

Demostración

Situación: Una aplicación de control asume que las marcas temporales del sensor son monótonas. Reconocimiento: En un despliegue con retardo de red intermitente, un sensor entrega marcas temporales más antiguas que el algoritmo trata como nuevas, provocando actualizaciones de estado incorrectas. Acción: Los desarrolladores añaden comprobaciones de orden de marcas temporales, toleran reordenamientos e incluyen pruebas unitarias e de integración para jitter de red. Consecuencia: La corrección evita que el defecto latente provoque acciones de control inseguras bajo condiciones de red retardada.

Aplicación incorrecta

Tratar cada resultado incorrecto observado como un 'bug' aislado atribuible únicamente a un error de codificación del desarrollador; el error ignora que muchos defectos se originan en requisitos, interfaces o supuestos operativos y que el mismo modo de fallo puede resultar de diferencias de configuración o entorno.

Consecuencia

Los defectos de software no abordados producen causalmente fallos, salidas incorrectas, riesgos de seguridad, vulnerabilidades y costes económicos; reconocer el tipo de defecto determina la mitigación —corrección de código, clarificación de requisitos, cambios arquitectónicos, redundancia, monitorización o endurecimiento del entorno— e influencia las estrategias de pruebas y verificación.

Inversión

En arquitecturas tolerantes a fallos o redundantes, un defecto en un componente puede estar enmascarado a nivel de sistema y nunca provocar un fallo observable, por lo que la ausencia de fallo no implica ausencia de defectos; la verificación formal y las pruebas exhaustivas pueden eliminar clases de defectos en dominios acotados, pero no escalan trivialmente a sistemas complejos e interconectados.

Límite

Claramente dentro: Un error off‑by‑one en una rutina de indexación de arreglos que para ciertas entradas provoca corrupción de memoria. Caso límite: Una condición de carrera dependiente del tiempo que aparece sólo bajo carga y planificación específicas—el diagnóstico requiere replicar el entorno. Claramente fuera: Una falla de hardware (flip de bit por radiación) que causa un comportamiento incorrecto no es principalmente un defecto de software, aunque el software puede mitigar o revelar tales fallas.

Tensión semántica

Velocidad de entrega frente a aseguramiento: acelerar el desarrollo reduciendo la verificación aumenta el riesgo de que defectos latentes lleguen a producción, mientras que pruebas exhaustivas y métodos formales elevan coste y tiempo de entrega, exigiendo un compromiso contextual entre tiempo, coste y riesgo residual aceptable.

Síntesis

Un defecto de software es una discrepancia dependiente del contexto entre comportamiento deseado y real que requiere especificación, detección y remediación dirigida; la gestión de defectos combina requisitos claros, diseño modular, pruebas y controles operativos porque ninguna práctica por sí sola elimina todos los defectos en sistemas complejos.