Pruebas De Software

¿ES POSIBLE CONSTRUIR UN SOFTWARE QUE NO FALLA?

Con motivo del año de Turing –celebrado en 2012– el diario El País de España publicó esta noticia muy interesante. Comienza preguntándose si es posible construir sistemas de software que no fallen, ya que hoy en día estamos todos muy acostumbrados a que todos los sistemas fallan. Ya es parte del día a día verse afectado por la poca calidad de distintos sistemas de los que dependemos. El tema es que existen también miles de ejemplos de errores que han producido grandes tragedias, muertes, accidentes, pérdidas de miles de dólares, etc.

El artículo comienza dando ejemplos de catástrofes (típico en todo profeta del testing) y luego plantea un ejemplo real que da esperanzas de que exista un software “perfecto”, o al menos suficientemente bueno, como para no presentar fallos que afecten a los usuarios.

Este sistema que no ha presentado fallos durante años ha sido desarrollado con un lenguaje basado en especificación de reglas de negocio con las que se genera código y la verificación automática de estos sistemas generados.

El ejemplo planteado es el del sistema informático de la línea 14 del metro de París. Esta línea es la primera en estar completamente automatizada. ¡Los trenes no tienen conductor!

Son guiados por un software, y mucha gente viaja por día (al final del 2007, un promedio de 450.000 pasajeros toman esta línea en un día laboral). Hoy en día hay dos líneas de metro que funcionan con el mismo sistema en París: la línea 14 y la línea 1.

Según cuenta el artículo de El País, el sistema tiene 86.000 líneas de código ADA

(definitivamente no es ningún “hello world”3). Fue puesto en funcionamiento en 1998 y hasta 2007 no presentó ningún fallo.

¿A qué queremos llegar con esto? A que es posible pensar en que somos capaces de desarrollar software suficientemente bueno. Seguramente este sistema tenga errores, pero no se han manifestado. Eso es lo importante. ¿Y cómo lo garantizamos? Obviamente, con un testing suficientemente bueno. Para esto tenemos que ser capaces de verificar los comportamientos del sistema que son más típicos, que pueden afectar más a los usuarios, que son más importantes para el negocio. Obviamente esto estará limitado o potenciado por otros factores más relacionados al mercado, pero nosotros nos centraremos más en cómo asegurar la calidad con el menor costo posible, dejando esas otras discusiones un poco al margen.

Esta visión es un poco más feliz que la que siempre escuchamos de Dijkstra, que indica que el testing nos sirve para mostrar la presencia de fallos pero no la ausencia de ellos. ¡Lo cual es muy cierto! Pero no por esta verdad vamos a restarle valor al testing. Lo importante es hacerlo en una forma que aporte valor y nos permita acercarnos a ese software perfecto o mejor dicho: de calidad.

...