archivo

Archivos diarios: mayo 21, 2011

Me parece muy interesante la reflexión del desarrollador libanés Joseph Abou Nader, especializado en soluciones ERP y en la implantación de las mismas en diferentes organizaciones de diversos países del mundo (principalmente de Europa, África y Oriente Medio).

Comenta que (traducción libre): “La implementación (desarrollo) de software es amarga pero el fruto es dulce”.

Estoy de acuerdo en la esencia de lo que quiere transmitir, pero la realidad que se vive en muchos proyectos es que “La implementación (desarrollo) de software es amarga, pero el fruto todavía puede serlo más”.

Las técnicas de testing de caja blanca se realiza cuando el tester accede al código fuente de la aplicación y en consecuencia a los diferentes algoritmos y estructuras de datos utilizadas. La implementación de este tipo de pruebas requiere habilidades de programación, un conocimiento del framework de desarrollo y un cierto conocimiento funcional que permita conocer qué misión tienen determinadas clases y métodos.

Entre las técnicas de testing de caja blanca más conocidas tenemos la cobertura que consiste básicamente en la verificación de que todos los caminos lógicos de la aplicación son alcanzables teóricamente en función de los diferentes valores de entradas de los parámetros. Este tipo de pruebas, se automatizan con la ejecución de pruebas unitarias.

Otra técnica bastante conocida es la Mutation Testing que se suele utilizar para verificar la bondad de los métodos de testing utilizados. Se basa principalmente en realizar ligeras modificaciones en el programa que darían lugar a un comportamiento anómalo del mismo (resultados distintos) y verificar si la estrategia de testing utilizada es capaz de detectar estos cambios. Ejemplos de estos pequeños cambios lo podemos tener modificando el operador en las guardas de sentencias selectivas o iterativas, eliminando sentencias, etc…

Entre las críticas a esta estrategia de testing se encuentra el hecho de que hay que saber elegir muy bien cómo realizar las mutaciones, ya que hay que verificar que realmente lo que se cambia provoca un comportamiento diferente en el algoritmo porque lo mismo haces un cambio y no cambia de comportamiento.

Otra técnica de caja blanca la tenemos con la Fault Injection que persigue objetivos similares a la Mutation Testing (de hecho se considera a esta técnica como parte de la Fault Injection). Entre este tipo de técnicas tenemos la Code Insertion Testing, en la cual se introducen sentencias nuevas que provocan un error o un comportamiento anómalo en el sistema. Además de estas tećnicas, que se aplican en tiempo de compilación, la Fault Injection también aplica estrategias en tiempo de ejecución, como el hecho de provocar determinados fallos o excepciones del sistema que permitan estudiar el comportamiento del sistema en esos casos.

Una de las técnicas de testing de caja blanca más conocida es el análisis estático de código que tiene como objetivo principal evaluar (directa o indirectamente) la deuda técnica del software o lo que es lo mismo, evaluar el grado de mantenibilidad del sistema.

La mantenibilidad del sistema es una característica a la que no se suele dedicar suficiente atención, al fin y al cabo lo importante es que el sistema funcione (algo de lo que estoy totalmente de acuerdo), pero que una vez que se consigue debe ser compatible con el hecho de que el sistema sea escalable y pueda ser modificado a un coste razonable.

Además, por regla general, un sistema con una deuda técnica elevada será más propenso a tener errores.

Ver también:

Testing de caja negra.
Testing de caja gris.

No lo es. El problema consiste en no tener en cuenta la naturaleza adaptativa del proceso de desarrollo de software o que si bien, no se ha tenido en cuenta, no se plantee una renegociación del alcance del proyecto entre cliente o proveedor o se compense económica ese esfuerzo de más que se va a echar.

Lo ideal es que todas las partes tengan en cuenta que el desarrollo de software no es un proceso predictivo, lo que obliga a hacer cambios a lo largo del desarrollo y además pueden ocurrir contingencias que rompan los planteamientos iniciales.

¿Cómo se tiene en cuenta? Pues teniendo en cuenta en el proceso de presupuestar proyectos esta circunstancia. Generalmente se presupuesta pensando en que todo va a ir bien o dando un cierto margen por encima en el caso de que haya incertidumbre. Y lo peor de todo no es eso, sino que por regla general no se tiene previsto que después el producto hay que mantenerlo y que eso ocurrirá siempre (será poco o mucho lo que haya que ir adaptando, pero lo que es cierto es que ocurrirá).

Una vez que los presupuestos tienen en cuenta que un proyecto de desarrollo de software es de naturaleza adaptativa el siguiente paso es aplicar una metodología que se adapte a ello porque si bien con dinero suficiente se reducen los problemas, la utilización de una metodología adecuada permite optimizarlo, lo cual redunda en el beneficio de todas las partes, el cliente porque tendrá más margen de adaptación, el proveedor porque tendrá más controlado el proyecto y el usuario final porque progresivamente tendrá un producto que se aproxime más a sus necesidades.