Marcando la Pauta para las Pruebas Ágiles

Dada su naturaleza, la industria del software enfrenta el enorme reto de mantenerse al ritmo de las cambiantes necesidades del mercado, la competencia y la globalización. Esto hace que la brecha entre la liberación de los productos de software y su comercialización se reduzca cada vez más, marcando con ello una dinámica de “puesta en producción” muy acelerada.

Las metodologías de desarrollo ágil han surgido intentando generar sistemas con alta calidad y a la vez, con una reducción y simplificación de tareas. Bajo este enfoque, las pruebas de software han tomado un papel crucial, dada la necesidad de realizar pequeñas liberaciones “funcionalmente” estables, surgiendo así el testing ágil. Para entender éste, es importante comprender cómo es que las pruebas encajan a lo largo de todo el ciclo de vida del desarrollo de software (SDLC). La figura 1 muestra un diagrama de Scott Ambler [1] que a grandes rasgos expone el ciclo de vida de desarrollo de software ágil.

Figura 1. Ciclo de vida de desarrollo ágil

El testing ágil refiere un enfoque dinámico de las pruebas de software. Dicho enfoque supone que los requerimientos no son estables sino que se incrementan de forma continua o se encuentran en constante cambio, de acuerdo a las necesidades expresadas por el cliente. Asimismo, el cliente también juega un rol muy importante manteniendo una comunicación  cercana y continua con el equipo de desarrollo; la obtención de sus necesidades (requerimientos) no se considera como una fase separada del desarrollo del software, sino una parte integral del mismo.

Mientras que en las metodologías tradicionales las actividades de prueba normalmente se pueden iniciar hasta que la especificación de requisitos se encuentre completa, en el caso del testing ágil dichas tareas quedan inmersas dentro de cada iteración.

Por citar otra de las diferencias importantes entre las metodologías tradicionales de pruebas y las ágiles, podemos destacar que mientras las primeras tienen como objetivo primordial la validación del producto desarrollado, en las ágiles tiene gran peso su utilización como medio para guiar el desarrollo del software, sustituyendo así la definición formal de requisitos.

A continuación se presentan algunas prácticas y actividades de prueba, tomando en cuenta el enfoque ágil.

Identificar aspectos a probar. Considerar las siguientes preguntas como guía para el desarrollo de los casos de prueba:

• ¿Qué necesidades del usuario debe resolver este producto?
• ¿Cuáles son las más críticas desde el punto de vista del usuario? (relación con pruebas de aceptación).
• ¿Cuál es el comportamiento esperado? ¿Cuál es la secuencia de acciones? (historias de usuario)
• ¿Hay alguna dependencia especial en el sistema?
• ¿Existen requerimientos no funcionales? ¿Cuáles?
• ¿Cuáles son las limitaciones del software/hardware respecto a características, funciones, datos, tiempo, etc.?
• ¿Las descripciones son lo suficientemente completas para decidir cómo diseñar,  implementar y probar cada requisito y el sistema en sí como un todo?
• ¿Qué problemas y riesgos pudieran estar asociados con estos requisitos?

Definir el alcance de pruebas. Éste tiene que encontrarse perfectamente delimitado por cada uno de los entregables solicitados por el cliente en cada iteración. Puede identificarse respondiendo a las preguntas:

• ¿Qué necesidades del cliente van a ser incluídas en esta liberación?
• ¿Cuáles van a excluirse de las pruebas en este producto específico?
• ¿Qué es lo nuevo en esta liberación con respecto a otras?
• ¿Qué ha cambiado o se ha actualizado/corregido para este producto?

Identificar las métricas de pruebas. Elegir las métricas que se van a utilizar para dar seguimiento a los objetivos asociados a cada liberación.

Definir los niveles de pruebas que se aplicarán. Por ejemplo: unitarias, de integración, de aceptación.

Definir los tipos de prueba que se realizarán. Por ejemplo: funcionales, de carga, stress, seguridad, etcétera.

Definir estrategias de pruebas.

• Identificar las técnicas utilizar. Ejemplos: Pruebas exploratorias, Pruebas basadas en Riesgos, Pruebas automatizadas, etc.
• Identificar las herramientas de ejecución y de administración de pruebas usar, buscando principalmente aquellas cuyas plantillas de registro de defectos (por ejemplo), sean lo más simples y concisas posible, evitando trabajo redundante y exhaustivo; en el caso de herramientas de automatización, dependerán del lenguaje.
• Realizar la selección de los datos de pruebas.
• Definir cómo se va a preparar y configurar el ambiente de pruebas.

Definir el punto de terminación de las pruebas.

• ¿Cuándo continuar o detener las pruebas antes de entregar el sistema al cliente?
• ¿Qué criterios de evaluación deben cubrirse?
• ¿Qué criterios finales de aceptación deberán satisfacerse?

Pruebas de aceptación y ATDD

Las diversas metodologías ágiles (Scrum, eXtreme Programming, etcétera) de algún modo han promovido la aplicación de las pruebas, dado que éstas son indispensables para la liberación exitosa (con calidad) de cada entregable; con ello también se han diversificado las estrategias para abordar dichos proyectos. Es así que han ganado popularidad estrategias como el Desarrollo Dirigido por Pruebas (TDD -Test Driven Development) y el Desarrollo Dirigido por Pruebas de Aceptación (ATDD - Aceptance Test Driven Develepment).

Sobre este último enfoque, ATDD, algunos aspectos clave a mencionar son los siguientes:

• Toma como principal referencia al usuario final, al cliente.
• Utiliza historias de usuario como requisitos a los que se asocian pruebas de aceptación (escenarios).
• Las pruebas de aceptación dirigen el diseño/desarrollo del sistema, ver Figura 2.
• Requieren entrar tempranamente en detalles de implementación e instanciación de datos de pruebas

Figura 2. Proceso general de Desarrollo Dirigido por Pruebas de Aceptación.

De acuerdo al diccionario de la IEEE, cuando hablamos de pruebas de aceptación nos referimos a “aquellas pruebas formales con respecto a las necesidades, requerimientos y procesos de negocio del usuario, conducidas para determinar ya sea si un sistema satisface o no los criterios de aceptación y habilita al usuario, cliente o entidad autorizada para determinar si el sistema se acepta o no” [2].

Como ya decíamos, en ATDD cada necesidad del usuario final se representa a través de historias de usuario (al igual que en TDD, donde la base son las pruebas unitarias), y a su vez cada historia de usuario tiene asociados ciertos criterios de aceptación. Para cada criterio se deben diseñar los respectivos escenarios/pruebas de aceptación que deberán aprobarse; una vez que éstas pruebas han sido diseñadas, los desarrolladores comenzarán a programar el código fuente que permitirá satisfacerlas; por su lado los desarrolladores definirán las pruebas unitarias que evaluarán el cumplimiento de los requisitos (expresados en términos de criterios de aceptación).

Vale la pena reiterar que las Pruebas de Aceptación son sólo el medio para probar la funcionalidad del sistema, pero ATDD representa todo el proceso de desarrollo cuya finalidad es que el sistema se construya de acuerdo a la funcionalidad expresada por el usuario. Por eso es que las pruebas de aceptación se definen en lenguaje natural, de modo que puedan ser comprendidas por los usuarios o analista de negocios del cliente.

Al igual que la definición de cualquier escenario de prueba, se plantea que contenga como mínimo: Título, pre-requisitos / precondiciones, descripción/pasos, criterios de aceptación/resultado esperado, tipo de usuario.

Automatización

Una vez que hemos diseñado todas las pruebas de aceptación que cubrirán todos los criterios que serán avalados por el cliente, podemos proceder a su automatización en alguna herramienta de pruebas para tal objetivo, teniendo posibilidad de elegir entre varias en el mercado, desde algunas gratuitas con sus respectivas limitaciones, hasta aquellas  más completas  y/o complejas que se ofrecen para compra o en la nube, soportando diversas tecnologías, protocolos, sistemas operativos:  Selenium, soapUI, TOSCA testsuite, HP Quick Test Pro, SilkTest, IBM Rational Functional Tester, SOATest, TestPartner, Visual Studio Test Profesional, etc.

La automatización en sí ciertamente nos ayudará a agilizar la ejecución de dichas pruebas de aceptación, sin embargo es de considerar también el mantenimiento que dichos scripts de prueba requerirán, máxime cuando de antemano sabemos que los requerimientos cambiarán continuamente, de ahí que el tema de la automatización de pruebas juega un papel crucial en un marco de trabajo Ágil.

En mi particular punto de vista, se debería hacer una análisis de los costos asociados con el mantenimiento de código que implícitamente se tendrá con la automatización y evaluar a conciencia qué partes de la aplicación convendrá probar bajo esta técnica y cuáles no, pues quizás en otros casos pueda resultar más efectiva alguna otra técnica como las mismas pruebas exploratorias manuales, realizadas por supuesto por ingenieros de pruebas con la mayor pericia o experiencia posible.

Perfil del tester

El aspecto humano no debe dejar de analizarse. El personal de pruebas definitivamente debe contar con las siguientes características:

• Excelentes habilidades de comunicación (de vital importancia por toda la interacción que se da entre los miembros de los equipos).
• Pasión y entusiasmo por las pruebas.
• Muy fuertes habilidades de trabajo en equipo, no individualismo.
• Programación en lenguajes de scripting.
• Habilidad para trabajar bajo presión (constantes entregas rápidas).
• Liderazgo.

Si bien es cierto, las habilidades anteriormente señaladas, no sólo debieran estar presentes en testers de proyectos de pruebas ágiles, sino en cualquier ingeniero de pruebas. Sin embargo, para este tipo de proyectos podríamos casi decir que son “las imperdonables”, dada la dinámica con la que se suele trabajar.

Conclusión

En mi opinión, no buscaría decidir cuál metodología es mejor, sino más bien buscaría identificar claramente cuándo aplicar alguna y cuándo otra, dado que los proyectos son cambiantes, son diferentes en muchos aspectos, entre ellos en tamaño, en complejidad, etc. Toda esa serie de elementos nos permitirán definir si las metodologías ágiles son aplicables o no en cada caso. Creo también que puede incluso presentarse un híbrido de metodologías ágiles y convencionales, teniendo por supuesto muy claro cómo sacar mayor ventaja a los elementos que una y otra ofrecen.

Bibliografía:

[2] [IEEE 610]  IEEE Std 610-1991, IEEE Computer Dictionary – Compilation of IEEE Standard Computer Glossaries, IEEE.