QAustral

Un Blog de QAustral SA – Calidad de Software y Negocios

Home » Posts tagged "bug"

Happy Tester’s Day!

“On September, 9 (1945) the scientists of the Harvard University while testing the computer Mark II Aiken Relay Calculator have found a moth which has got stuck between the contacts of the electromechanical relay. The work they performed required some description, and the word has been found – «debugging» (literally: disposal of an insect) – and nowadays it is used to describe the process of identifying and eliminating bugs which cause a computer to malfunction. The removed insect was pasted into the computer log with the entry: “First actual case of bug being found”, and was then transferred to the computer museum. (…)This informal holiday became quite popular – Happy Tester’s Day!”

Fallas de software (parte XI)

Explosión de cohete Ariadne 5 (1996)

El 6 de junio de 1996 se culpó a una computadora por la explosión del primer vuelo, el 501, del cohete Ariadne 5 con un costo de 500 millones de dólares. El cohete, que al parecer no estaba asegurado, llevaba 4 satélites, cuya explosión ocasiono pérdidas totales de 1800 millones de dólares. El Ariadne 5 estaba funcionando perfectamente hasta los 40 segundos iníciales, cuando de repente empezó a salirse de su trayectoria y solo fracciones de segundo después, fue destruido por control remoto mediante una señal enviada por un controlador del Ariadne desde Tierra. Según la European Spacial Agency (ESA), administradora del programa, la desviación en la trayectoria fue ocasionada por la computadora que controlaba los dos poderosos impulsores del cohete. Se especulo que la computadora creyó que el cohete se estaba saliendo de curso y de esta manera trataba de corregir la trayectoria de vuelo. De acuerdo con el reporte final, la causa de la falla del sistema ocurrió durante la conversión de un número flotante de 64 bits a un número entero de 16 bits. Al convertir un numero con punto flotante daba como resultado un valor mayor que él podía ser representado por un numero entero de 16 bits (con signo), ocasionando un error de operando. Las instrucciones de conversión de datos (código Ada) no estaban protegidas para evitar el error de operando, aunque otras conversiones en variables similares en el mismo lugar si lo estaban (quizás al desarrollador le dio flojera terminar de validar jeje) . El origen del problema radico en que el Ariadne 5 podía llevar una mayor numero de satélites que el Ariadne 4, incrementando así su peso. Sin embargo, el Ariadne 5 utilizaba una gran cantidad de software diseñado para el Ariadne 4 (hicieron el típico copy paste)

Fallas en el software (parte X)

Administradora de capital de riesgo quiebra por datos incorrectos en un modelo de computo (1994)

En 1994 la compañía Askin Capital Management, un imperio de fondos de cobertura de 600 millones de dólares, quebró por culpa de valuaciones imprecisas insertadas a un modelo utilizado para negociar garantías basadas en hipotecas.

Error en el procesador Pentium de Intel (1994)

En 1994, un error de punto flotante en el procesador Pentium le costó a Intel 475 millones de dólares. El error no fue reconocido públicamente durante meses por Intel, declarando que el procesador era “suficientemente bueno” y que sería muy difícil que sucediera un error. Además la generación Pentium III de 1 GHz fue retirada del mercado, por lo menos saben reconocer sus errores.

Fuente:despistadolux.wordpress.com

Fallas en el software (parte IV)

Muertes por el Terac-25 ( 1985-1987)

El acelerador lineal médico Therac-25, producido por Atomic Energy of Canadá Limited ( AECI), fue diseñado para tratamientos de radiación de dos tipos (1) tratamiento de rayo directo de bajo poder y (2)tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 esté sistema ocasionó la muerte de varios pacientes en diferentes hospitales de Estado Unidos y Canadá debidó a las radiaciones de alto poder aplicadas sin control. A partir de ciertas secuencias de comandos del operador de la máquina, los controles de la computadora lo llevaban a un estado interno erróneo muy peligroso, generado por una sobredosis masivá de radiación. Después de una amplia publicidad de estos accidentes, se descubrio que la Federal Drug Agency (FDA) no especificaba requisitos, ni hacía revisiones sobre las prácticas de desarrollo o control de calidad del software en dispositivos médicos. La FDA informó en 1987 que comenzaría a exigir controles de software integrados a ciertas clases de dispositivos médicos. Lamentablemente, en muchos de estos sistemas el operador también juega un papel crítico, como en el caso de Panamá en 2001, donde datos insertados incorrectamente por los operadores durante tratamientos de cáncer mediante radiación ocasionaron la muerte de 5 personas en esté país. Aunque la falla no fue directamente atribuida al software, se supone que el sistema de radicación contaba con protección para prevenir la radiación de tejido sano.

Fallas en el software (parte III)

Sobregiro del Bank of New York (1985)

En noviembre de 1985, el Bank of New York (BoNY) tuvo accidentalmente un sobregiro dede 32000 millones de dólares ( ! una gran suma si se considera que fue en 1985 ¡ ). Esto fue causado por un contador de 16 bits ( la mayoria de los contadores eran de 32 bits) que se activo provocando un overflow (la cantidad fue demasiado para el y no pudo contenerla) del contador que nunca fue verificado. El banco no pudo procesar nuevas transferencias, por lo que la Reserva Federal de Nueva York automáticamente hizo un traspaso de 24000 millones de dólares al BoNY para cubrir sus gastos de un día. El banco tuvo QUE PAGAR 5 MILLONES DE DOLARES DE INTERESES DIARIOS, mientras se arreglaba el software.

La importancia de la norma ISTQB

La norma internacional ISTQB, es en la actualidad la norma superior que certifica la calidad de los profesionales que intervienen en el testing de alto nivel. Pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software.

El Comité internacional de cualificación de pruebas de software (ISTQBTM: International Software Testing Qualification Board, www.istqb.org) es una organización, creada en el año 2002, con el fin de suportar y definir un esquema de certificación internacional. Dicho comité suministra el plan de estudios y el glosario en los cuales se definen los estándares internacionales por nivel y se establecen las guías para la acreditación y evaluación de los profesionales del testing a cargo de los comités de cada país.

Las pruebas de software se integran dentro de las diferentes fases del Ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.
Las pruebas de software, testing o beta testing es un proceso usado para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. “El testing puede probar la presencia de errores pero no la ausencia de ellos”, E. W. Dijkstra.

Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra. Una definición de “testing” es: proceso de evaluación de un producto desde un punto de vista crítico, donde el “tester” (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Por supuesto, nunca se debe testear el software en un entorno de producción. Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producción es necesario crear las mismas condiciones que en la máquina de producción. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.

En general, los informáticos distinguen entre errores de programación (o “bugs”) y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo.
Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de “testers” al finalizar su desarrollo y antes de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versión del producto en pruebas y que es anterior a la versión final (o “master”) se denomina beta, y a dicha fase de pruebas, beta testing.
Puede además existir una versión anterior en el proceso de desarrollo llamada alpha, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser testeado.
Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing (Release To Market), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.

Otra práctica es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y continúe hasta que finaliza.