Nombre: Dina Marcela Rios Madrigal

Taller pruebas de Software

1. Investigue sobre algunos momentos históricos que se generaron en tragedia por no haber
realizado pruebas de software, a partir de la investigación realice una sopa de letras.
RESPUESTA
El primer bug conocido fue un bug físico. Literalmente. Una polilla entre los relés del Mark
II causó errores en su funcionamiento allá por el 1947.

Por desgracia, en lugar de ser una excepción, encontrar errores en el software es un

problema común. En muchos casos, estos errores son simplemente un fastidio sin graves
consecuencias y que se arreglan con una nueva versión del software sin que haya que
lamentar mayores daños.

Pero no hay que olvidar que el software está en todas partes y que un error en un
software ofimático puede que nos acordemos de la madre del programador/a de turno
pero un error en un software médico o de control de sistemas críticos puede tener
consecuencias mucho más fatales.

Sin ánimo de ser catastrofista (y siguiendo con mi “manía” de la importancia de enseñar la

historia de la informática), os animo a seguir leyendo esta lista de los peores errores de la
historia del software. Fijaros especialmente en el porqué de los errores, a ver si así
evitamos repetirlos. En cada error comentamos el desencadenante principal pero siempre
vino acompañado de una cadena de fallos que a partir de ese error acabó generando el
fatal desenlace. Y es que ésa es la gran dificultad en todo proceso de “debugging”. El error
nunca es obvio y sólo aparece en condiciones muy específicas en las que muchas veces no
hemos pensado (y por tanto no escribimos el test correspondiente).

LA EXPLOSIÓN DEL ARIANE 5. MIL MILLONES DE DOLARES PERDIDOS

Y un retraso en muchas de las investigaciones que debían llevarse a cabo en el cohete. ¿El
problema? En gran parte, la reutilización de código.

Y es que parte del código del Ariane 5 se reutilizó del Ariane 4. Y aunque los dos eran
cohetes de la misma familia no eran exactamente iguales y lo que en uno no dió
problemas acabo en desastre en el otro en menos de 40 segundos.

Técnicamente hablando el causante del error fue que en una parte del código se intentaba
copiar una variable de 64 bits en una de 16 con el consiguiente error de overflow. Esto no
había dado problemas en el Ariane 4 ya que por sus características la variable de 64 nunca
tomaba un valor mayor que lo que cabía en 16 bits pero no así en el Ariane 5.

Un ejemplo carísimo de la típica excusa “en mi ordenador funciona”

EXCESO DE RADIACIÓN EN EL THERAC-25 MATÓ A CINCO PACIENTES

Nada peor que un bug que acaba provocando la muerte de personas. Este es el caso de la
máquina de radiación Therac-25 que por un error en su software de control suministró un
exceso de radiación a varios pacientes provocando la muerte de al menos cinco de ellos.

La causa está en errores en el control de la concurrencia de las diferentes rutinas que se

ejecutaban en paralelo, entre ellos un problema “clásico”, una race condition que inducía
la máquina a emitir radiación a potencia máxima si una determinada secuencia de eventos
inesperados se producía.

MARS CLIMATE ORBITER. EL ERROR DE CONVERSIÓN QUE NOS DEJÓ SIN FOTOS DE MARTE
El Mars Climate Orbiter tenía como misión fotografiar Marte durante años. Pero no llegó a
enviar ni una. Y todo por un fallo tan “tonto” como un error de conversión. El sistema de
control de la nave en la Tierra usaba el sistema métrico anglosajón mientras que el
sistema de navegación de la nave esperaba valores en el sistema métrico decimal. Esto
hizo que la trayectoria de la nave se acercara demasiado a Marte y acabará desintegrada
por la fuerza de fricción atmosférica del planeta.

En este caso, el error tuvo su origen en el incumplimiento de los requisitos del sistema que
especificaba que todo el software debía usar el sistema métrico decimal. Muy buen
ejemplo de la importancia de cumplir (y testear) que la implementación del software
cumple con su especificación.

CUANDO DESPLEGAR LA VERSIÓN INCORRECTA DEL SOFTWARE A PRODUCCIÓN TE

CUESTA MÁS DE 400 MILLONES DE DOLARES EN 45 MINUTOS
Éste es otro error clásico, que en este caso concreto costo al grupo Knight Capital 460
millones de dolares en menos de una hora. Y es que desplegar una nueva versión del
software a producción siempre es una operación de riesgo, sobretodo en el caso de
algoritmos de “trading” especializados en la compra-venta de acciones casi instantáneas.

Entre otros problemas, se les “olvidó” cambiar la configuración del algoritmo para decirle
que iba a ejecutarse en producción en lugar de en modo “test” (donde, justamente para
probar su comportamiento en condiciones extremas, se eliminaban muchas de las
restricciones que tenían que regular su comportamiento). Y claro, el algoritmos se dedicó
a comprar y vender alegremente sin evaluar las consecuencias.

EL PROBLEMA DEL AÑO 2000. EL “ERROR” QUE DIO DE COMER A MUCHOS

INFORMÁTICOS
No podemos acabar sin mencionar el error más mediático. Los que tenemos una cierta
edad nos pasamos los últimos años del siglo XX años escuchando relatos apocalípticos que
explicaban que el mundo se iba a parar en el año 2000 debido a la multitud de sistemas
informáticos que iban a dejar de funcionar.

El problema era que muchos programas antiguos almacenaban la fecha usando sólo dos
dígitos para el año, para así ahorrar espacio. Con lo que para ellos, el año 2000 sería 1900,
lo que haría que, por ejemplo, jubilados dejaran de cobrar su pensión al rejuvenecer 100
años.

Al final el número de sistemas afectados fue bastante limitado, en gran parte por la
previsión de muchas empresas que se aseguraron de revisar y actualizar sus sistemas.

Por eso mismo digo que este tipo de error habitual (una excesiva optimización que no
previó los efectos negativos a largo plazo) al final tuvo un efecto beneficioso en nuestra
profesión ya que fue uno de los causantes del crecimiento de empleo en informática
alrededor de esos años. Y es que no hay mal que por bien no venga.

Y AÚN MÁS ERRORES

Errores graves hay (y habrá) muchos más. Para una lista más exhaustiva de errores podéis
consultar esta entrada de la wikipedia o esta otra (más corta pero que explica mejor cada
error) Pero creo que los citados anteriormente son, cada uno de ellos, ejemplos
representativos de distintos tipos de situaciones que os encontraréis en algún momento
(espero que con posibles consecuencias mucho más leves). ¡Que os sirvan de lección!

Ah, y que nadie se piense que los informáticos somos los únicos ingenieros que la pifian.
Aquí tenéis una serie de televisión con errores garrafales de otros tipos de ingenieros que,
normalmente, tienen mejor fama.
 SOPA DE LETRAS

2. Haga un mapa mental digital donde resuma los siguientes conceptos

Calidad de software
Pruebas de software
Requisitos funcionales
Requisitos no funcionales
Tipos de prueba
Niveles de prueba

LINK DE ACCESO A MAPA MENTAL EN MIRO

https://miro.com/welcomeonboard/
NG45bTVRV0NHNzBkdVRSbkJYYnhVc1BTTUd0bWc3WTFnRzB5TU92cHdwM2JMZE5RWm9
TZ2ZROHJ1UEVma3RudXwzNDU4NzY0NTE5MTgyNjY5MjI2?share_link_id=914831534615

3. Haga una tabla comparativa donde muestre las diferencias entre técnicas de caja negra y
caja blanca.

CAJA NEGRA CAJA BLANCA

No conoce los detalles internos del programa Conoce la estructura interna del programa
Solo conoce las especificaciones
No son una alternativa, complementan las de
la caja blanca
Intenta encontrar errores en
 Funciones incorrectas o faltantes
 Errores de interfaz
 Errores en la estructura de datos
 Errores de comportamiento o
rendimiento
 Errores de inicialización y terminación
Requiere análisis del código fuente para
diseñar los casos de prueba
Garantiza que se ejercita por lo menos una vez
todos los caminos independientes de cada
modulo
Ejercita todas las decisiones lógicas en sus
vertientes verdadera y falsa
Ejercitan todos los bucles en sus limites y
limites operacionales
Ejercita la estructura interna de los datos para
asegurar su validez