Error de programación

Un error de software es un error, defecto o falla en el diseño, desarrollo o funcionamiento de un software informático que hace que produzca un resultado incorrecto o inesperado, o que se comporte de forma no deseada. El proceso de búsqueda y corrección de errores se denomina "depuración" y, a menudo, utiliza técnicas o herramientas formales para identificar errores. Desde la década de 1950, algunos sistemas informáticos han sido diseñados para disuadir, detectar o autocorregir varios errores informáticos durante las operaciones.

Los errores en el software pueden surgir de errores y errores cometidos al interpretar y extraer usuarios' requisitos, la planificación del diseño de un programa, la escritura de su código fuente y la interacción con humanos, hardware y programas, como sistemas operativos o bibliotecas. Un programa con muchos errores, o graves, a menudo se describe como defectuoso. Los errores pueden desencadenar errores que pueden tener efectos dominó. Los efectos de los errores pueden ser sutiles, como el formato de texto no deseado, hasta efectos más obvios, como hacer que un programa se bloquee, congelar la computadora o dañar el hardware. Otros errores califican como errores de seguridad y pueden, por ejemplo, permitir que un usuario malintencionado eluda los controles de acceso para obtener privilegios no autorizados.

Algunos errores de software se han relacionado con desastres. Los errores en el código que controlaba la máquina de radioterapia Therac-25 fueron directamente responsables de las muertes de pacientes en la década de 1980. En 1996, el cohete prototipo Ariane 5 de la Agencia Espacial Europea, valorado en mil millones de dólares, fue destruido menos de un minuto después del lanzamiento debido a un error en el programa informático de guía a bordo. En 1994, un helicóptero Chinook de la RAF se estrelló, matando a 29; esto se atribuyó inicialmente a un error del piloto, pero luego se pensó que había sido causado por un error de software en la computadora de control del motor. El software con errores provocó el escándalo de la oficina de correos británica de principios del siglo XXI, el error judicial más generalizado en la historia legal británica.

En 2002, un estudio encargado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de EE. UU. concluyó que "los errores o errores de software son tan frecuentes y perjudiciales que le cuestan a la economía de EE. estimado en $59 000 millones anuales, o alrededor del 0,6 por ciento del producto interno bruto".

Historia

La palabra del inglés medio bugge es la base de los términos "bugbear" y "bugaboo" como términos usados para un monstruo.

El término "error" describir defectos ha sido parte de la jerga de la ingeniería desde la década de 1870 y es anterior a la electrónica y las computadoras; es posible que se haya utilizado originalmente en ingeniería de hardware para describir fallas mecánicas. Por ejemplo, Thomas Edison escribió en una carta a un asociado en 1878:

... surgen dificultades—esta cosa da y [es] entonces que "Bugs"—como tan poco fallas y dificultades se llaman—muéstrese ellos mismos

Baffle Ball, el primer juego de pinball mecánico, se anunciaba como "libre de errores" en 1931. Los problemas con el equipo militar durante la Segunda Guerra Mundial se denominaron errores (o fallas). En un libro publicado en 1942, Louise Dickinson Rich, hablando de una máquina cortadora de hielo motorizada, dijo: "El aserrado del hielo se suspendió hasta que se pudiera traer al creador para quitarle los bichos a su amada".

Isaac Asimov usó el término "bicho" para relacionar los problemas con un robot en su cuento "Catch That Rabbit", publicado en 1944.

Una página del registro de la computadora electromecánica de Harvard Mark II, con una polilla muerta que fue eliminada del dispositivo.

El término "error" fue utilizado en un relato por la pionera de la informática Grace Hopper, quien publicó la causa de un mal funcionamiento en una de las primeras computadoras electromecánicas. Una versión típica de la historia es:

En 1946, cuando Hopper fue liberada del servicio activo, se incorporó a la Facultad de Harvard en el Laboratorio de Computación, donde continuó su trabajo en los Marcos II y Marcos III. Los operadores rastrearon un error en la marca II a una polilla atrapada en un relé, acuñando el término bug. Este fallo fue cuidadosamente eliminado y grabado en el libro de registro. Robando del primer error, hoy llamamos errores o fallos en un programa un bug.

Hopper no estaba presente cuando se encontró el error, pero se convirtió en una de sus historias favoritas. La fecha en el libro de registro era el 9 de septiembre de 1947. Los operadores que lo encontraron, incluido William "Bill" Burke, más tarde del Laboratorio de Armas Navales, Dahlgren, Virginia, estaba familiarizado con el término de ingeniería y mantuvo divertido el insecto con la anotación "Primer caso real de error encontrado". Este libro de registro, completo con polilla adjunta, es parte de la colección del Museo Nacional Smithsonian de Historia Estadounidense.

El término relacionado "depurar" también parece ser anterior a su uso en informática: el Oxford English Dictionary'etimología de la palabra contiene una atestación de 1945, en el contexto de los motores de aviones.

El concepto de que el software puede contener errores se remonta a las notas de 1843 de Ada Lovelace sobre el motor analítico, en las que habla de la posibilidad de que las "tarjetas" porque el motor analítico de Charles Babbage es erróneo:

... un proceso de análisis debe igualmente haberse realizado para dotar al motor analítico de lo necesario operativo operativo operativo los datos; y que en el presente documento también puede mentir una posible fuente de error. Concedido de que el mecanismo real no esté en sus procesos, tarjetas puede darle órdenes equivocadas.

"Errores en el sistema" informe

El Open Technology Institute, dirigido por el grupo New America, publicó un informe "Errores en el sistema" en agosto de 2016, declarando que los legisladores estadounidenses deberían hacer reformas para ayudar a los investigadores a identificar y abordar los errores de software. El informe "destaca la necesidad de una reforma en el campo del descubrimiento y divulgación de vulnerabilidades de software." Uno de los autores del informe dijo que el Congreso no ha hecho lo suficiente para abordar la vulnerabilidad del software cibernético, a pesar de que el Congreso aprobó una serie de proyectos de ley para combatir el problema más amplio de la seguridad cibernética.

Los investigadores gubernamentales, las empresas y los expertos en seguridad cibernética son las personas que normalmente descubren fallas de software. El informe pide reformar las leyes de derechos de autor y delitos informáticos.

Ley de fraude y abuso informáticos, Ley de derechos de autor del Milenio digital y privacidad de las comunicaciones electrónicas Act criminalize and create civil penalties for actions that security investigators routinely engage in while conducting legitimate security research, the report said.

Terminología

Si bien el uso del término "error" describir errores de software es común, muchos han sugerido que debería abandonarse. Un argumento es que la palabra "bug" está divorciado de la sensación de que un ser humano causó el problema y, en cambio, implica que el defecto surgió por sí solo, lo que lleva a abandonar el término "error" a favor de términos como "defecto", con un éxito limitado. Desde la década de 1970, Gary Kildall sugirió con cierto humor usar el término "equivocación".

En ingeniería de software, metamorfismo erróneo (del griego meta = "cambiar", morph = " form") se refiere a la evolución de un defecto en la etapa final de la implementación del software. Transformación de un "error" cometido por un analista en las primeras etapas del ciclo de vida de desarrollo de software, lo que conduce a un "defecto" en la etapa final del ciclo se ha denominado 'metamorfismo erróneo'.

Distintas etapas de un "error" en todo el ciclo puede describirse como "errores", "anomalías", "fallas", "fallas", "errores" 34;, "excepciones", "fallas", "problemas técnicos", "errores", "defectos", &# 34;incidentes" o "efectos secundarios".

Prevención

Error resultante de un error de software mostrado en dos pantallas en la estación La Croix de Berny en Francia.

La industria del software se ha esforzado mucho en reducir el número de errores. Éstas incluyen:

Errores tipográficos

Los errores suelen aparecer cuando el programador comete un error lógico. Varias innovaciones en el estilo de programación y la programación defensiva están diseñadas para hacer que estos errores sean menos probables o más fáciles de detectar. Algunos errores tipográficos, especialmente de símbolos u operadores lógicos/matemáticos, permiten que el programa funcione incorrectamente, mientras que otros, como la falta de un símbolo o un nombre mal escrito, pueden impedir que el programa funcione. Los lenguajes compilados pueden revelar algunos errores tipográficos cuando se compila el código fuente.

Metodologías de desarrollo

Varios esquemas ayudan a administrar la actividad del programador para que se produzcan menos errores. La ingeniería de software (que también aborda problemas de diseño de software) aplica muchas técnicas para prevenir defectos. Por ejemplo, las especificaciones formales del programa establecen el comportamiento exacto de los programas para que se puedan eliminar los errores de diseño. Desafortunadamente, las especificaciones formales no son prácticas para nada excepto para los programas más cortos, debido a problemas de explosión combinatoria e indeterminación.

Las pruebas unitarias implican escribir una prueba para cada función (unidad) que debe realizar un programa.

En la unidad de desarrollo basada en pruebas, las pruebas se escriben antes que el código y el código no se considera completo hasta que todas las pruebas se completan con éxito.

El desarrollo de software ágil implica lanzamientos de software frecuentes con cambios relativamente pequeños. Los defectos son revelados por los comentarios de los usuarios.

El desarrollo de código abierto permite que cualquier persona examine el código fuente. Una escuela de pensamiento popularizada por Eric S. Raymond como la ley de Linus dice que el software popular de código abierto tiene más posibilidades de tener pocos o ningún error que otro software, porque "con suficientes ojos, todos los errores son superficiales& #34;. Sin embargo, esta afirmación ha sido cuestionada: el especialista en seguridad informática Elias Levy escribió que "es fácil ocultar vulnerabilidades en un código fuente complejo, poco comprendido e indocumentado" porque, "incluso si las personas están revisando el código, eso no significa que estén calificados para hacerlo". Un ejemplo de un error de software de código abierto fue la vulnerabilidad OpenSSL de 2008 en Debian.

Soporte de lenguaje de programación

Los lenguajes de programación incluyen funciones para ayudar a prevenir errores, como sistemas de tipos estáticos, espacios de nombres restringidos y programación modular. Por ejemplo, cuando un programador escribe (pseudocódigo) LET REAL_VALUE PI = "TRES Y UN BIT", aunque esto puede ser sintácticamente correcto, el código falla en una verificación de tipo. Los lenguajes compilados captan esto sin tener que ejecutar el programa. Los lenguajes interpretados detectan tales errores en tiempo de ejecución. Algunos lenguajes excluyen deliberadamente características que conducen fácilmente a errores, a expensas de un rendimiento más lento: el principio general es que casi siempre es mejor escribir código más simple y lento que código inescrutable que se ejecuta un poco más rápido, especialmente considerando que el costo de mantenimiento es sustancial.. Por ejemplo, el lenguaje de programación Java no admite la aritmética de punteros; Las implementaciones de algunos lenguajes, como Pascal y los lenguajes de secuencias de comandos, a menudo tienen límites de tiempo de ejecución que verifican las matrices, al menos en una compilación de depuración.

Análisis de código

Las herramientas para el análisis de código ayudan a los desarrolladores al inspeccionar el texto del programa más allá de las capacidades del compilador para detectar posibles problemas. Aunque, en general, el problema de encontrar todos los errores de programación dada una especificación no tiene solución (consulte el problema de detención), estas herramientas explotan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples a menudo cuando escriben software.

Instrumentación

Las herramientas para monitorear el rendimiento del software mientras se ejecuta, ya sea específicamente para encontrar problemas como cuellos de botella o para garantizar el funcionamiento correcto, pueden estar incrustadas en el código explícitamente (tal vez tan simple como una declaración que diga IMPRIMIR "ESTOY AQUÍ"), o proporcionadas como herramientas. A menudo es una sorpresa encontrar dónde la mayor parte del tiempo lo ocupa un fragmento de código, y esta eliminación de suposiciones puede hacer que el código se reescriba.

Pruebas

Los probadores de software son personas cuya tarea principal es encontrar errores o escribir código para respaldar las pruebas. En algunos proyectos, es posible que se gasten más recursos en las pruebas que en el desarrollo del programa.

Las mediciones durante las pruebas pueden proporcionar una estimación de la cantidad de posibles errores restantes; esto se vuelve más confiable cuanto más tiempo se prueba y desarrolla un producto.

Depuración

El historial de errores típico (datos del proyecto GNU Classpath). Un nuevo error presentado por el usuario es sin confirmar. Una vez que ha sido reproducido por un desarrollador, es un confirmado bicho. Los errores confirmados son más tarde fijo. Los errores pertenecientes a otras categorías (inreproducibles, no se fijarán, etc.) suelen estar en la minoría.

Encontrar y corregir errores, o depurar, es una parte importante de la programación informática. Maurice Wilkes, uno de los primeros pioneros de la informática, describió su descubrimiento a fines de la década de 1940 de que pasaría gran parte del resto de su vida encontrando errores en sus propios programas.

Por lo general, la parte más difícil de la depuración es encontrar el error. Una vez que se encuentra, corregirlo suele ser relativamente fácil. Los programas conocidos como depuradores ayudan a los programadores a localizar errores ejecutando el código línea por línea, observando los valores de las variables y otras funciones para observar el comportamiento del programa. Sin un depurador, se puede agregar código para que los mensajes o valores se puedan escribir en una consola o en una ventana o archivo de registro para rastrear la ejecución del programa o mostrar valores.

Sin embargo, incluso con la ayuda de un depurador, localizar errores es un arte. No es raro que un error en una sección de un programa provoque fallas en una sección completamente diferente, lo que hace que sea especialmente difícil de rastrear (por ejemplo, un error en una rutina de procesamiento de gráficos que hace que falle una rutina de E/S de archivo), en una parte aparentemente no relacionada del sistema.

A veces, un error no es una falla aislada, sino que representa un error de pensamiento o planificación por parte del programador. Dichos errores lógicos requieren que una sección del programa sea revisada o reescrita. Como parte de la revisión del código, revisar el código e imaginar o transcribir el proceso de ejecución a menudo puede encontrar errores sin siquiera reproducir el error como tal.

Por lo general, el primer paso para localizar un error es reproducirlo de forma fiable. Una vez que el error es reproducible, el programador puede usar un depurador u otra herramienta mientras reproduce el error para encontrar el punto en el que el programa se desvió.

Algunos errores son revelados por entradas que pueden ser difíciles de recrear para el programador. Una de las causas de las muertes de la máquina de radiación Therac-25 fue un error (específicamente, una condición de carrera) que ocurrió solo cuando el operador de la máquina ingresó muy rápidamente a un plan de tratamiento; se necesitaron días de práctica para poder hacer esto, por lo que el error no se manifestó en las pruebas o cuando el fabricante intentó duplicarlo. Otros errores pueden dejar de ocurrir cada vez que se aumenta la configuración para ayudar a encontrar el error, como ejecutar el programa con un depurador; estos se llaman heisenbugs (nombrados con humor por el principio de incertidumbre de Heisenberg).

Desde la década de 1990, particularmente después del desastre del vuelo 501 de Ariane 5, aumentó el interés en las ayudas automatizadas para la depuración, como el análisis de código estático mediante interpretación abstracta.

Algunas clases de errores no tienen nada que ver con el código. La documentación o el hardware defectuosos pueden generar problemas en el uso del sistema, aunque el código coincida con la documentación. En algunos casos, los cambios en el código eliminan el problema aunque el código ya no coincida con la documentación. Los sistemas integrados con frecuencia solucionan errores de hardware, ya que hacer una nueva versión de una ROM es mucho más económico que remanufacturar el hardware, especialmente si son artículos básicos.

Comparativa de errores

Para facilitar la investigación reproducible sobre pruebas y depuración, los investigadores utilizan puntos de referencia seleccionados de errores:

• el parámetro Siemens
• ManyBugs es un referente de 185 errores C en nueve programas de código abierto.
• Defects4J es un referente de 341 errores Java de 5 proyectos de código abierto. Contiene los parches correspondientes, que cubren una variedad de tipo parche.

Gestión de errores

La gestión de errores incluye el proceso de documentación, categorización, asignación, reproducción, corrección y publicación del código corregido. Los cambios propuestos al software (errores, así como solicitudes de mejora e incluso lanzamientos completos) se rastrean y administran comúnmente mediante sistemas de seguimiento de errores o sistemas de seguimiento de problemas. Los elementos agregados pueden llamarse defectos, tickets, problemas o, siguiendo el paradigma de desarrollo ágil, historias y epopeyas. Las categorías pueden ser objetivas, subjetivas o una combinación, como el número de versión, el área del software, la gravedad y la prioridad, así como el tipo de problema, como una solicitud de función o un error.

Una clasificación de errores revisa los errores y decide si corregirlos y cuándo hacerlo. La decisión se basa en la prioridad del error y en factores como los cronogramas del proyecto. La clasificación no está destinada a investigar la causa de los errores, sino el costo de solucionarlos. El triaje ocurre regularmente y pasa por errores abiertos o reabiertos desde la reunión anterior. Los asistentes al proceso de selección suelen ser el director del proyecto, el director de desarrollo, el director de pruebas, el director de compilación y los expertos técnicos.

Gravedad

Gravedad es la intensidad del impacto que tiene el error en el funcionamiento del sistema. Este impacto puede ser la pérdida de datos, financiera, pérdida de buena voluntad y esfuerzo desperdiciado. Los niveles de gravedad no están estandarizados. Los impactos difieren según la industria. Una falla en un videojuego tiene un impacto totalmente diferente a una falla en un navegador web o un sistema de monitoreo en tiempo real. Por ejemplo, los niveles de gravedad de los errores pueden ser "bloqueo o bloqueo", "sin solución alternativa" (lo que significa que no hay forma de que el cliente pueda realizar una tarea determinada), "tiene una solución alternativa" (lo que significa que el usuario aún puede realizar la tarea), "defecto visual" (por ejemplo, falta una imagen, un botón desplazado o un elemento de formulario) o "error de documentación". Algunos editores de software utilizan niveles de gravedad más calificados, como "crítico", "alto", "bajo", "bloqueador" o "triviales". La gravedad de un error puede ser una categoría separada de su prioridad de corrección, y los dos pueden cuantificarse y gestionarse por separado.

Prioridad

Prioridad controla dónde cae un error en la lista de cambios planificados. La prioridad la decide cada productor de software. Las prioridades pueden ser numéricas, como del 1 al 5, o con nombre, como "crítica", "alta", "baja" o "diferida". 34;. Estas escalas de calificación pueden ser similares o incluso idénticas a las calificaciones de gravedad, pero se evalúan como una combinación de la gravedad del error con su esfuerzo estimado para solucionarlo; un error de gravedad baja pero fácil de solucionar puede tener una prioridad más alta que un error de gravedad moderada que requiere un esfuerzo excesivo para solucionarlo. Las clasificaciones de prioridad pueden alinearse con los lanzamientos de productos, como "crítico" prioridad que indica todos los errores que deben corregirse antes de la próxima versión del software.

Un error lo suficientemente grave como para retrasar o detener el lanzamiento del producto se denomina "show stopper" o "error espectacular". Se llama así porque "detiene el espectáculo" – provoca un fallo inaceptable del producto.

Lanzamientos de software

Es una práctica común lanzar software con errores conocidos de baja prioridad. Los errores de prioridad suficientemente alta pueden justificar una publicación especial de una parte del código que contiene solo módulos con esas correcciones. Estos se conocen como parches. La mayoría de los lanzamientos incluyen una combinación de cambios de comportamiento y varias correcciones de errores. Las versiones que enfatizan la corrección de errores se conocen como versiones de mantenimiento, para diferenciarlas de las versiones principales que enfatizan la adición o cambios de funciones.

Las razones por las que un editor de software opta por no parchear o incluso corregir un error en particular incluyen:

• Debe cumplirse un plazo y los recursos son insuficientes para corregir todos los fallos antes del plazo.
• El fallo ya está fijado en una próxima liberación, y no es de alta prioridad.
• Los cambios necesarios para corregir el fallo son demasiado costosos o afectan demasiados otros componentes, lo que requiere una actividad de prueba importante.
• Es posible que se sospeche o se sepa que algunos usuarios confían en el comportamiento del buggy existente; una solución propuesta puede introducir un cambio de ruptura.
• El problema está en un área que estará obsoleta con una próxima liberación; arreglarlo es innecesario.
• "No es un bicho, es una característica". Ha surgido un malentendido entre comportamiento esperado y percibido o característica indocumentada.

Tipos

En los proyectos de desarrollo de software, se puede introducir una equivocación o error en cualquier etapa. Los errores surgen de la supervisión o malentendidos por parte de un equipo de software durante la especificación, el diseño, la codificación, la configuración, la entrada de datos o la documentación. Por ejemplo, un programa relativamente simple para ordenar alfabéticamente una lista de palabras, el diseño podría no tener en cuenta lo que debería suceder cuando una palabra contiene un guión. O al convertir un diseño abstracto en código, el codificador podría crear sin darse cuenta un error de uno en uno que puede ser un "<" donde "<=" fue intencionado, y fallan al ordenar la última palabra en una lista.

Otra categoría de error se denomina condición de carrera que puede ocurrir cuando los programas tienen múltiples componentes ejecutándose al mismo tiempo. Si los componentes interactúan en un orden diferente al previsto por el desarrollador, podrían interferir entre sí y evitar que el programa complete sus tareas. Estos errores pueden ser difíciles de detectar o anticipar, ya que es posible que no ocurran durante cada ejecución de un programa.

Los errores conceptuales son la falta de comprensión de un desarrollador sobre lo que debe hacer el software. El software resultante puede funcionar de acuerdo con el entendimiento del desarrollador, pero no lo que realmente se necesita. Otros tipos:

Aritmética

En las operaciones con valores numéricos, pueden surgir problemas que den como resultado resultados inesperados, la ralentización de un proceso o bloqueos. Estos pueden deberse a una falta de conocimiento de las cualidades del almacenamiento de datos, como una pérdida de precisión debido al redondeo, algoritmos numéricamente inestables, desbordamiento o subdesbordamiento aritmético, o por falta de conocimiento de cómo los diferentes lenguajes de codificación de software manejan los cálculos, como como división por cero que en algunos idiomas puede generar una excepción y en otros puede devolver un valor especial como NaN o infinito.

Flujo de control

Los errores de flujo de control son aquellos que se encuentran en procesos con lógica válida, pero que conducen a resultados no deseados, como bucles infinitos y recursividad infinita, comparaciones incorrectas para declaraciones condicionales como el uso del operador de comparación incorrecto y errores de uno por uno. (contar una iteración de más o de menos cuando se realiza un bucle).

Interfaz

• Uso incorrecto de API.
• Aplicación incorrecta del protocolo.
• Manejo incorrecto de hardware.
• Hipótesis incorrectas de una plataforma en particular.
• Sistemas incompatibles. Un nuevo protocolo de API o comunicaciones puede parecer funcionar cuando dos sistemas utilizan diferentes versiones, pero pueden ocurrir errores cuando una función o característica implementada en una versión se cambia o se pierde en otra. En los sistemas de producción que deben funcionar continuamente, no es posible cerrar todo el sistema para una actualización importante, como en la industria de telecomunicaciones o en Internet. En este caso, segmentos más pequeños de un sistema grande se actualizan individualmente, para minimizar la perturbación a una red grande. Sin embargo, algunas secciones pueden pasar por alto y no actualizarse, y causar errores de compatibilidad que pueden ser difíciles de encontrar y reparar.
• Anotaciones de código incorrecto.

Concurrencia

• Deadlock, donde la tarea A no puede continuar hasta que la tarea B termine, pero al mismo tiempo, la tarea B no puede continuar hasta que la tarea A termine.
• Condición de carrera, donde el ordenador no realiza tareas en el orden que el programador pretendía.
• Errores de coincidencia en secciones críticas, exclusiones mutuas y otras características del procesamiento simultáneo. El tiempo de check-to-time-of-use (TOCTOU) es una forma de sección crítica sin protección.

Recursos

• Dereferencia de puntero nulo.
• Usando una variable no inicializada.
• Usando una instrucción de otra manera válida sobre el tipo de datos incorrectos (ver decimal empaquetado/decimal codificado binario).
• Violaciones de acceso.
• Las fugas de recursos, donde un recurso del sistema finito (como las manijas de memoria o archivos) se agotan mediante una asignación reiterada sin liberación.
• Desbordamiento de amortiguación, en el que un programa intenta almacenar datos más allá del final del almacenamiento asignado. Esto puede o no conducir a una violación de acceso o violación del almacenamiento. Estos son frecuentes errores de seguridad.
• La recursión excesiva que, aunque lógicamente válida, causa el desbordamiento de la pila.
• Error sin uso, donde se utiliza un puntero después de que el sistema ha liberado la memoria que hace referencias.
• Doble error gratis.

Sintaxis

• Uso del token equivocado, como realizar tareas en lugar de probar la igualdad. Por ejemplo, en algunos idiomas x=5 establecerá el valor de x a 5 mientras x==5 comprobará si x es actualmente 5 o algún otro número. Los idiomas interpretados permiten que este código falle. Los idiomas compilados pueden capturar tales errores antes de comenzar las pruebas.

Trabajo en equipo

• Actualizaciones no propuestas; por ejemplo, el programador cambia "myAdd" pero olvida cambiar "mySubtract", que utiliza el mismo algoritmo. Estos errores son mitigados por la filosofía de Don't Repita usted mismo.
• Comentarios fuera de la fecha o incorrecta: muchos programadores asumen los comentarios con precisión describen el código.
• Diferencias entre documentación y producto.

Implicaciones

La cantidad y el tipo de daño que puede causar un error de software afecta naturalmente la toma de decisiones, los procesos y la política con respecto a la calidad del software. En aplicaciones como los vuelos espaciales tripulados, la aviación, la energía nuclear, la atención médica, el transporte público o la seguridad automotriz, dado que las fallas del software tienen el potencial de causar lesiones humanas o incluso la muerte, dicho software tendrá mucho más escrutinio y control de calidad que, por ejemplo, un sitio web de compras en línea. En aplicaciones como la banca, donde las fallas de software tienen el potencial de causar daños financieros graves a un banco oa sus clientes, el control de calidad también es más importante que, por ejemplo, una aplicación de edición de fotografías.

Aparte del daño causado por los errores, parte de su costo se debe al esfuerzo invertido en solucionarlos. En 1978, Lientz et al. mostró que la mediana de los proyectos invierte el 17 por ciento del esfuerzo de desarrollo en la corrección de errores. En 2020, la investigación sobre los repositorios de GitHub mostró que la mediana es del 20 %.

Errores residuales en el producto entregado

En 1994, el Centro de Vuelo Espacial Goddard de la NASA logró reducir su número promedio de errores de 4,5 por 1000 líneas de código (SLOC) a 1 por 1000 SLOC.

Otro estudio de 1990 informó que los procesos de desarrollo de software excepcionalmente buenos pueden lograr tasas de fallas de implementación tan bajas como 0,1 por 1000 SLOC. Esta cifra se reitera en publicaciones como Code Complete de Steve McConnell y el estudio de la NASA sobre la complejidad del software de vuelo. Algunos proyectos incluso alcanzaron cero defectos: el firmware de la máquina de escribir IBM Wheelwriter, que consta de 63.000 SLOC, y el software del transbordador espacial con 500.000 SLOC.

Errores conocidos

Varios errores de software se han vuelto conocidos, generalmente debido a su gravedad: los ejemplos incluyen varios accidentes de aviones militares y espaciales. Posiblemente, el error más famoso es el problema del año 2000 o el error Y2K, que causó que muchos programas escritos mucho antes de la transición de las fechas 19xx a 20xx no funcionaran correctamente, por ejemplo, al tratar una fecha como "25 de diciembre de 04" como en 1904, mostrando "19100" en lugar de "2000", y así sucesivamente. Un gran esfuerzo a finales del siglo XX resolvió los problemas más graves, y no hubo mayores consecuencias.

La interrupción del comercio de acciones de 2012 implicó una incompatibilidad de este tipo entre la antigua API y una nueva API.

En la cultura popular

• En la novela de 1968 2001: A Space Odyssey y la correspondiente película de 1968 2001: A Space OdysseyUna nave espacial está a bordo del ordenador, HAL 9000, intenta matar a todos sus miembros de la tripulación. En la novela de seguimiento de 1982, 2010: Odyssey Dos., y la película acompañante de 1984, 2010, se revela que esta acción fue causada por la computadora que había sido programada con dos objetivos contradictorios: divulgar plenamente toda su información, y mantener el verdadero propósito del vuelo secreto de la tripulación; este conflicto hizo que HAL se paranoico y eventualmente homicida.
• En la versión inglesa de la canción Nena 1983 99 Luftballons (99 Globos Rojos) como resultado de los "bugs in the software", una liberación de un grupo de 99 globos rojos se equivocan para un lanzamiento de misiles nucleares enemigos, que requiere una respuesta de lanzamiento equivalente, resultando en catástrofe.
• En la comedia americana de 1999 Oficina espacial, tres empleados intentan (sin éxito) explotar la preocupación de su empresa con el fallo informático Y2K usando un virus informático que envía fracciones redondeadas de un centavo a su cuenta bancaria, una técnica conocida descrita como corte de salami.
• La novela de 2004 El error, por Ellen Ullman, es sobre el intento de un programador de encontrar un error elusivo en una aplicación de la base de datos.
• La película canadiense 2008 Control Alt Delete se trata de un programador de computadoras a finales de 1999 que lucha por corregir errores en su empresa relacionados con el problema del año 2000.