archivo

Archivo de la etiqueta: Edsger W. Dijkstra

La rigurosidad del testing debe depender del nivel de criticidad del sistema que se va a poner en producción, ya sea en primera instancia o como consecuencia de una evolución del mismo. Esta rigurosidad se tendrá que ver reflejada en todas las etapas de desarrollo del software y tiene como objetivo evitar que lleguen a producción errores que sean críticos para el sistema y que puedan provocar un coste en vidas humanas o unas pérdidas económicas que puedan poner en jaque la subsistencia de una organización.

Esta rigurosidad estará relacionada con el número de casos de prueba a los que se somete el software, desde la misma definición de las pruebas unitarias a las pruebas de carácter funcional, así como a la propia verificación de la bondad de la técnica utilizada.

Hoy en día existen implantaciones software en sistemas empotrados, sistemas de información, etc… que manejan todo tipo de cosas. Como cada vez está más extendida la automatización, cada vez son mayores los sectores donde el software maneja funciones críticas. Incluso funciones que se pueden considerar no críticas, como por ejemplo la web de una organización, cada vez tiene un mayor grado de criticidad tanto en cuanto la forma en que muchos clientes acceden a la misma es través de Internet.

Por tanto, cada día que pasa es más importante que un producto llegue a producción tras superar un umbral de calidad específico definido para el mismo que permita tener confianza en una reducción importante de la probabilidad de que se produzcan errores críticos.

Hacer un buen testing no es sencillo, así como seleccionar el conjunto finito de casos que se va a estudiar (incrementar la cardinalidad de ese conjunto depende de factores económicos y el presupuesto debería estar ajustado a la criticidad del producto), ya que de el mismo depende que posibles errores importantes se puedan colar en producción.

Sobre esto es conveniente recordar una cita muy conocida de Edsger Wybe Dijkstra en la que comenta que: “El testing de los programas puede ser muy efectivo para mostrar la presencia de errores, sin embargo resulta inadecuado para mostrar su ausencia”.

Desarrollar un software sin errores es una entelequia, por muchas vueltas que le demos siempre se llegará a producción con incidencias, lo cual no quita que haya que intentar que sean lo menos graves y las menores posibles.

En esta entrada recojo dos citas de dos maestros en el desarrollo de software como son Edsger Wybe Dijkstra y Brian Wilson Kernighan (que algo saben de todo esto) y que están referidas al proceso de depuración del software en el proceso de construcción, entendiendo que la depuración forma parte del mismo como lo es la propia codificación.

Codificar sin depurar traerá como es lógico resultados nefastos y depurar completamente el código no es posible, por tanto es importante llegar al justo medio en función de las características del sistema y de las posibilidades que tengamos para hacerlo.

Los errores en la codificación son algo natural al proceso de desarrollo, la experiencia y las habilidades personales de cada uno pueden disminuir su proporción, pero nadie, por muy bueno que sea es infalible y por tanto debe considerarse como algo natural y por supuesto corregible, ya que para eso está la depuración.

[Dijkstra]: “Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos.”

[Khernigan]: “Depurar es al menos dos veces más duro que escribir el código por primera vez. Por tanto, si tu escribes el código de la forma más inteligente posible no serás, por definición, lo suficientemente inteligente para depurarlo”.