archivo

Archivo de la etiqueta: testing ágil

Boris Beizer es un autor e ingeniero de software americano (aunque nacido en Bélgica) especializado en el campo de la calidad del software y del testing. Sus primeras publicaciones datan de finales de la década de los cincuenta, aunque su etapa más prolífica fue en las décadas de los setenta y de los ochenta.

El testing es un campo dentro de la ingeniería del software un tanto controvertido. La mayoría de los profesionales consideramos necesarias las pruebas en el proyecto de desarrollo de software, si bien no hay coincidencia en cuanto a la intensidad, los momentos y la metodología.

Soy de la opinión de que no todos los proyectos y sistemas de información deben tener un mismo tratamiento y que independientemente de que exista una cierta metodología en las pruebas, estas deben girar alrededor del testing ágil y del exploratorio.

También soy partidario de que las clases con mayor acoplamiento sean cubiertas mediante pruebas unitarias (no necesariamente desarrollando según técnicas de desarrollo guiadas por las pruebas (TDD)) y que se deben minimizar los efectos colaterales a través de las pruebas de regresión.

En cuanto a los momentos, el testing debe aplicarse desde las etapas más tempranas del software, si bien los actores pueden ser distintos a las pruebas realizadas sobre el producto.

Y como estrategia, la utilización de integración continua permite detectar problemas de carácter unitario y de integración lo antes posible y a reducir los problemas en la fase de implantación.

Boris Beizer realiza la siguiente reflexión (traducción libre): “Una amenaza bien vale mil pruebas”.

Desgraciadamente nos acordamos de un proceso de testing bien realizado cuando ya los errores han salido a la luz y lo peor de eso, cuando su corrección requiere de un esfuerzo considerable, cuando ha impactado gravemente en el negocio o cuando nos crea un problema.

Cuando mayor sea la criticidad del sistema más peso debe tener el proceso de testing y más peso debe cobrar la metodología y sistematización.

En el artículo anterior vimos las actividades que definían al proceso de implantación y de las consecuencias de que el tiempo necesario para realizar esa actividad superasen unos umbrales admisibles para el proyecto de desarrollo de software en cuestión.

La aplicación de una metodología o enfoque ágil o la utilización, en general, de alternativas iterativas e incrementales suponen por su propia naturaleza una disminución de los tiempos de implantación, sobre todo, una vez que ya se han realizado varias evoluciones del sistema.

Sin embargo, si el tiempo necesario para realizar las implantaciones resulta superior al tiempo de iteración definido tenemos un problema ya que provoca una acumulación de las entregas y que buena parte del tiempo invertido en el proceso de implantación se pierda. Esta situación no debería mantenerse mucho tiempo y para solucionarla sería necesario retrasar una entrega hasta que se pueda subir una acumulación de evoluciones a producción.

Estas situaciones pueden producirse en más ocasiones de las que podemos pensar, ya que lo mismo los trabajos siguiendo metodologías ágiles, parten de una versión del producto avanzada y que no ha sido implantada todavía (o no se han implantado con éxito), los equipos encargados de testing y de paso a producción tienen una carga de trabajo elevada, otras prioridades, etc…

Soy de la opinión de que para poder trabajar de manera adecuada hay que estabilizar la situación, es decir, si la implantación de un producto resulta compleja o está dando problemas, hay que centrar los esfuerzos en ella y adaptar los desarrollos que se están haciendo a esa circunstancia.

Además de la aplicación de enfoques ágiles, ayuda mucho la existencia de unos entornos de integración y de preproducción los más parecidos posibles a los de reales, la aplicación de la integración continua, la utilización de técnicas de desarrollo guiadas por las pruebas (TDD) o al menos la aplicación de una estrategia adecuada de aplicación de pruebas unitarias, para reducir de esta forma la aparición de efectos colaterales y disminuir los tiempos necesarios para las pruebas de regresión y la corrección de este tipo de incidencias.

Además de lo anterior es importante que con carácter previo a la entrega el producto haya sido probado de manera adecuada por el equipo de proyecto (nada de entregas a ciegas o de pruebas superficiales).

También resulta muy adecuado el establecimiento de itinerarios de testing (todas las aplicaciones no requieren el mismo nivel de testing, ni todas las circunstancias son similares), la aplicación de testing ágil, proporcionar a los proveedores información detallada sobre las características de nuestro entorno de producción, la aplicación de una política de prioridades a los equipos encargados del paso a producción acorde a la problemática existente en cada momento, etc…

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.