¿Por qué son importantes las pruebas de software?

Definitivamente si se quieres iniciar una charla de debe de hacer con esta pregunta, de hecho, en conferencias siempreinicio con ella y lo hago ponderando varios ejemplos, ya que entiendo que sonla forma mas efectiva de dejarlo claro.

Por supuesto antes debemos definir que son laspruebas de software: las pruebas de software se definen como una actividad paraverificar si los resultados reales coinciden con los resultados esperados ypara tratar de garantizar que el sistema de software no salga a producción condefectos críticos o perjudiciales ya que acorde con los principios de pruebasno podemos garantizar que el software va a salir sin defectos, en cambio lo quesi podemos garantizar es que los defectos más críticos serán atacados antes de supuesta en producción. Esto implica la ejecución de un componente de software ocomponente del sistema para evaluar una o más propiedades (atributos defuncional o no funcional de la calidad de software) de interés.

En palabras más simples, las pruebas desoftware significan verificar la aplicación bajo prueba.

Hoy por hoy nosotros no podemos concebir elmundo tal cual lo conocemos sin la intervención la de ingeniería de software, lascomunicaciones, la salud, el transporte, la banca y hasta el entretenimiento, sonllevados a cabo por aplicaciones de software cada vez más complejas para podercumplir con las exigencias del mercado.

Un pequeño fallo en uno de estos aspectos puedeafectarnos directa o indirectamente, un fallo de cálculo en una aplicación bancariapuede causarnos daños económicos, un fallo en el software de un aparato utilizadopara la salud puede causar hasta la muerte cuyo valor económico no se puedecalcular o imaginémonos un fallo en el software de un avión en pleno vuelo,esto puede causar ambos tipos de perdidas, y de hecho a pasado, veamos algunos ejemplosde los fallos que valen la pena recordar

La explosión del ariane 5. Mil millones de dólares perdidos

Un retraso en muchas de las investigaciones quedebían llevarse a cabo en el cohete. ¿El problema? En gran parte, lareutilización de código.

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

Técnicamente hablando el causante del error fueque en una parte del código se intentaba copiar una variable de 64 bits en unade 16 con el consiguiente error de overflow. Esto no había dado problemas en elAriane 4 ya que por sus características la variable de 64 nunca tomaba un valormayor 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 miordenador funciona”

Exceso de radiación en el therac-25 mató a cinco pacientes

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

La causa está en errores en el control de laconcurrencia de las diferentes rutinas que se ejecutaban en paralelo, entreellos un problema “clásico”, una racecondition que inducía la máquina a emitirradiación a potencia máxima si una determinada secuencia de eventos inesperadosse producía.

Cuando desplegar la versión incorrecta del software a producción te cuesta más de 400 millones de dólares en 45 minutos.

Éste es otro error clásico, que en este casoconcreto costo al grupo Knight Capital 460 millones de dólares en menos de unahora. Y es que desplegar una nueva versión del software a producción siempre esuna operación de riesgo, sobre todo en el caso de algoritmos de “trading”especializados en la compraventa de acciones casi instantáneas.

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

Mas errores.

Estos errores son solo una muestra de lo quepuede pasar si no probamos bien antes de pasar a producción, y denotan conextrema claridad el punto que queremos tratar.

Si deseas ver una lista más exhaustiva deerrores puedes consultar esta entrada de la Wikipedia o esta otra (más corta pero que explicamejor cada error).