archivo

Archivo de la etiqueta: testing de caja negra

Las pruebas de aceptación son aquellas realizadas por los usuarios con carácter previo al paso a producción de una nueva versión del producto. Se trata de pruebas de caja negra en un entorno de preproducción en la que se verifican si las funcionalidades pactadas para la entrega y recogidas en catálogos de requisitos, casos de uso, historias de usuario u otro hito documental, cumplen las expectativas del usuario.

El problema de este tipo de pruebas es que en demasiadas ocasiones los usuarios (o sus jefes) rechazan invertir tiempo suficiente para realizar estas tareas de testing y en otras, los equipos de desarrollo tampoco ponen demasiado interés en ello.

En desarrollos siguiendo metodologías clásicas o en cascada si no se ha hecho participar al usuario en fases posteriores al análisis y no se han hecho ajustes, las pruebas de aceptación servirán para poco porque probablemente, salvo que el desarrollo sea de poco alcance, habrán variado las condiciones iniciales o bien el usuario se encontrará con una implementación que aún respetando los requisitos (que está por ver) será complicado que verifique lo que se imaginaba que iba a hacer el sistema.

Sin embargo en mantenimiento evolutivos o correctivos pequeños, ciclos de vida iterativos incrementales (con sprints de corta duración) o mediante la aplicación de metodologías ágiles, este tipo de pruebas sí que tendrían una gran utilidad porque se evita pasar evoluciones a producción que pueden afectar a un trabajo eficiente de los usuarios con la aplicación.

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.