a.- Hacia los test automatizados

Hemos sentado la premisa que la certificación del producto lo hacemos todos. A su vez también hemos establecido las abstracciones como una de las claves del avance de la informática.

En paralelo a esas abstracciones, podemos ver la automatización como una de las calves del avance de la sociedad.

Esa misma automatización se debería aplicar a los procesos de software, de manera que no sólo el creador es el que decide cómo se debe comportar, sino que además decide cómo se debería probar ese comportamiento y auto-suministra métodos para llevar esas comprobaciones a cabo.

Al final siempre el creador es el más interesado en que su producto funcione bien. Por tanto el objetivo de esta creación es hacia la automatización de las pruebas, que el 90% del comportamiento del aplicativo sea predecible y comprobado automáticamente. Y a su vez seamos el resto de la comunidad los que identifiquemos ese 10% restante.

Pero siempe será mejor que sea el 10% y no el 90%. Sin duda la creación de estos test automatizados es una referencia directa a la calidad del producto.

A su vez es otra indicación hacia la in necesidad de entornos de pruebas o certificación, debido a que esas mismas pruebas se harán automáticamente.

Lenguajes como perl disponen de miles de test automatizados y ya Drupal está siguiendo el mismo camino, donde los desarrolladores, no sólo hacen el módulo en cuestión sino a su vez indican y generan una serie de test que debe pasar ese módulo.

Se trata sin duda de la correcta interpretación del proceso de pruebas, donde el que decide cómo se debe probar es el más indicado, por tanto quién ha realizado el componente.