archivo

Archivo de la etiqueta: criticidad

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”.

Uno de los aspectos más complicados del testing consiste en definir hasta dónde se va a llegar, es decir, qué tipo de pruebas realizar y con qué intensidad, ya que todo el software no tiene la misma criticidad, los mismos recursos para su desarrollo, los mismos plazos, etc…

Es un error aplicar el mismo nivel de testing a todos los productos, ya que podemos pecar por exceso o por defecto (siempre mejor, como es lógico el exceso) y además hay que tener en cuenta que el testing se debería medir más por su efectividad y por su calidad que por el tiempo dedicado al mismo, si bien, se entiende que un equipo formado, aplicando una serie de metodologías y utilizando una serie de herramientas, mantendrá un nivel de efectividad más o menos regular por unidad de tiempo.

A lo anterior hay que añadir que el testing se debe realizar en todo el proceso de desarrollo y no solo al final y que el mismo equipo de proyecto debe participar en el mismo mediante la aplicación de pruebas unitarias, integración continua, pruebas funcionales, verificaciones continuas con el usuario y obtención e implementación del feedback, etc…, independientemente de que existan una serie de profesionales que sean especialistas en realizar este tipo de trabajo.

El testing es muy importante y no una disciplina secundaria, no es algo que se debiera infravalorar, como en el mundo de la programación hay programadores buenos, malos y regulares, lo mismo pasa con los testers. Un producto que llega a producción con errores graves va a costar dinero, de una u otra forma. En algunos casos estos errores serán críticos y el coste será elevadísimo en otros casos provocará un parón en el servicio que no es poco.

Resulta muy interesante la siguiente cita de Weinberg porque refleja bien a las claras lo crítico que resulta en muchas ocasiones el proceso de testing y lo complicado que resulta establecer sus límites (traducción libre): “En septiembre de 1962, saltó a la luz una noticia que indicaba que un cohete de 18 millones de dolares había sido destruido en pleno vuelo debido a un simple guión que faltaba en un programa. La naturaleza de la programación es así, ya que no existe relación entre el tamaño del error y los problemas que causa. Por tanto, es difícil definir cualquier objetivo en el proceso de testing, sin llegar a la eliminación de todos los errores, algo que resulta imposible”.