archivo

Archivo de la etiqueta: testing de caja blanca

Mutation testing es una técnica de pruebas de caja blanca que surgió en la década de los setenta que se utiliza para realizar una verificación de la calidad de los métodos y procedimientos de testing utilizados.

El motivo principal de la utilización de este tipo de estrategias es la de comprobar si las pruebas definidas son correctas y cubren los requerimientos del sistema que se está verificando. A veces se definen pruebas que efectivamente dan por válidas las salidas correctas de un determinado programa, pero que también dan por válidas otras salidas que deberían ser erróneas, es decir, nos centramos en comprobar que el resultados que esperamos se produce sin pensar en que lo mismo hay otras formas anómalas de producir resultados que además son incorrectos.

¿En qué consiste la técnica? En realizar ligeras modificaciones al código fuente original que deberían provocar unos resultados diferentes al normal y comprobar si la técnica de testing utilizada puede 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…

Si la técnica de testing no ha detectado el cambio puede ser por dos motivos, por un lado que los cambios en el código fuente no han sido ejecutados (ya sea porque ese fragmento de código no se ejecuta nunca) o porque la estrategia de testing ha fallado. Para intentar que este tipo de situaciones no provoque falsos positivos lo que se hace es incluir mutaciones en zonas cubiertas por pruebas unitarias (y que se ha verificado que el código puede llegar a ejecutarse) o bien realizar mutaciones en diversas zonas del código.

En el desarrollo de software, pese a que las bases de las metodologías ágiles se establecieron en el manifiesto ágil (año 2001) y algunas de ellas ya existían con bastante antelación al mismo, su popularidad ha crecido exponencialmente sobre todo en los últimos años.

Es cierto que al principio podría considerarse como una tendencia o una moda, pero el agilismo llegó para quedarse, ya que presenta una alternativa real a las metodologías tradicionales para combatir a la crisis del software en ciertos tipos de proyectos.

Sin embargo, esta popularidad tiene también su parte negativa y entre ellas se encuentra el hecho de que se ha empezado a utilizar el término ágil para multitud de temáticas relacionadas con el desarrollo del software, con mayor o menor cierto según el caso y que ha provocado una pérdida de valor, por inflacción, de la palabra ágil y sus derivados.

Como no podría ser de otra forma, si tenemos desarrollos ágiles (basados en metodologías ágiles), también nos vamos a encontrar con testing ágil.

Consiste en la aplicación de los principios del desarrollo ágil en el testing.

Uno de ellos consiste en situar la acción sobre el procedimiento. El testing se realiza con un fin que es la detección de incidencias (a ser posible, las más críticas) a lo largo del proceso de desarrollo de software, si bien lo más habitual (aunque no lo más conveniente) es intentar encontrarlas como paso previo a la implantación del software.

En muchos casos se entiende como certificación de un producto, sin embargo resulta complicado llegar a ese extremo porque habría primero que alcanzar un acuerdo con respecto a qué nivel debe alcanzar una entrega software para considerarse certificada.

Soy de la opinión de que al testing le hace mucho daño asociarlo con certificación (pudo o puede ser una estrategia comercial, pero a larga resulta negativa) porque a su vez se asocia certificación a “sin fallos” y hay que tener en cuenta que en la mayoría de los casos el software va a pasar a producción con incidencias, en algunos casos serán importantes y en otros casos no afectarán al correcto funcionamiento del sistema o a la eficiencia en la utilización del mismo por parte de los usuarios.

Lo importante, por tanto, no debe ser darle un nombre al resultado del testing, sino encontrar errores, deficiencias, carencias y cuanto antes mejor.

El testing ágil puede ser aplicable a proyectos basados en metodologías ágiles como en metodologías clásicas, si bien la coincidencia de principios entre unos y otros los hace más eficientes.

En el caso de metodologías ágiles resulta fundamental la utilización de testing ágil, ya que si los ciclos de vida son iterativos e incrementales y el objetivo es adaptar el software a las necesidades y demandas del usuario, se necesita de un testing que se adapte a esa forma de trabajar, que suponga una ayuda y no un obstáculo.

El testing ágil como el propio proceso de desarrollo de software basado en metodologías ágiles, debe estar centrado en conseguir que el usuario se vaya encontrando iteración tras iteración con un sistema que cada vez se acerca más a lo que estaba esperando, por tanto el testing ágil, pese a que tenga en cuenta aspectos que influyen en lo funcional (en cuanto a que la composición de los mismos proporcionan las funcionalidades, pero no asegura que se haya acertado con lo que el usuario espera), como es la validación de los caminos lógicos del software mediante pruebas unitarias, debe estar centrado en la perspectiva del usuario respecto del sistema o lo que es lo mismo, las funcionalidades y la interacción y esto puede ser revisado desde incluso etapas previas al desarrollo de la iteración, mediante la revisión de requisitos, historias de usuario o casos de uso, de manera conjunta con el usuario, ayudándole a interpretar cómo quedaría en el sistema de información.

No es incompatible lo anterior con la automatización de pruebas, antes al contrario, todo lo que pueda ser automatizado permite centrar la atención en el resto del sistema e incrementar las probabilidades de encontrar nuevas incidencias. Por tanto, el testing ágil, puede ser compatible con la realización de testing de caja blanca, de caja negra y de caja gris, la clave consiste en elegir lo que resulte más adecuado a la naturaleza del proyecto.

Existe por tanto una relación estrecha entre el testing exploratorio y el ágil, en el sentido del enfoque adaptativo, es decir, tenemos un producto que se está desarrollando, en las condiciones particulares de un proyecto de desarrollo de software en el cual han podido ocurrir infinidad de contingencias y que ha podido ser llevado a cabo siguiendo cualquier metodología (o ninguna), por tanto hay que adaptarse a lo que hay, a lo que el equipo de testing se encuentra. Podrá solicitar ayuda al equipo de desarrollo, pero no debería interferir en su funcionamiento solicitando documentación formal que lo mismo no existe.

Lo importante, sobre todo, es la comunicación entre los equipos de desarrollo y de testing.

Es cierto que a veces esa forma de trabajar es similar a dejarnos en medio de un bosque, de noche y sin brújula, al principio estaremos desorientados pero con el paso del tiempo conoceremos cada vez mejor el medio.

El concepto de testing de caja gris es simple, se basa en la realización de testing de caja negra basado en casos de prueba realizados por personas que conocen el programa por dentro. Se entiende que de esta forma las pruebas realizadas son más efectivas porque se conocen las partes del código que pueden resultar más conflictivas: por su complejidad, por su acoplamiento con otras clases, etc…

Por regla general cuando nos encontramos que el equipo de desarrollo diseña casos de prueba se centra en aspectos funcionales sin tener en cuenta cómo se ha desarrollado la aplicación, algo que resulta curioso ya que se tiene conocimiento suficiente para poder diseñar este tipo de pruebas. ¿Por qué sucede esto? Pues porque no se le da la importancia que se merece al testing y luego pasa lo que pasa y se entregan los productos en el estado en que se entregan.

Parece que todo lo ajeno a la construcción es accesorio, prescindible o incluso una pérdida de tiempo. Yo no entiendo el desarrollo de software sin la realización de un testing acorde a las características del proyecto, como tampoco lo entiendo sin una documentación en función de lo que se necesite.

Ver también: Testing de caja blanca.

Esta estrategia de testing se centra en la verificación de las funcionalidades de la aplicación: Datos que entran, resultados que se obtienen, interacción con los actores, funcionamiento de la interfaz de usuario y en general todo aquello que suponga estudiar el correcto comportamiento que se espera del sistema.

Por tanto la diferencia fundamental respecto al testing de caja blanca es que en este caso no se trabaja con el código fuente sino con el programa, no importa en este caso cómo se consigue la funcionalidad de un módulo sino que el mismo responda de la manera en que debería según las especificaciones del sistema.

No se trata de elegir una estrategia u otra, sino de elegir para cada proyecto lo que más convenga. Probablemente lo más acertado sea aplicar técnicas de ambos mundos, aunque lo más normal suele ser que se apliquen técnicas de caja negra con técnicas de caja blanca que suponen menos esfuerzo (o ninguno) como el análisis estático de código. Al final siempre será cuestión de disciplina, analizar coste y beneficio y la apuesta por una metodología o forma concreta de trabajar.

Ver también: Testing de caja gris.

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.