Las metodologías ágiles de desarrollo de software, conllevan diferencias importantes en las pruebas ágiles de software respecto al enfoque predictivo.
Bajo una metodología de desarrollo de software en cascada, el equipo de Testing está enfocado en una única fase del proyecto, la de pruebas de software. No comienza a contribuir hasta que el desarrollo de un módulo o funcionalidad está integrado. En la mayoría de los casos, el equipo de Testing no comienza desde la fase inicial.
Las pruebas ágiles de software implican cambios importantes respecto a estos métodos de trabajo, como por ejemplo que el equipo de Testing está integrado con el de desarrollo, es un solo equipo, las pruebas se realizan en paralelo con el desarrollo, los Testers colaboran con el dueño del producto en el levantamiento de requerimientos / historias de usuario.
Asimismo, los Testers en un entorno ágil necesitan conocer a profundidad en funcionamiento interno del software y le son indispensables las herramientas de automatización de pruebas.
Presentamos a continuación los 8 aspectos en los cuales se diferencian las pruebas ágiles de software.
1.- Integración de desarrolladores y testers de software en un solo equipo multifuncional
Tradicionalmente, la función de pruebas y calidad de software está completamente separada de la de desarrollo de software, en tal sentido:
- Existe un equipo de desarrollo y un equipo de Testing claramente diferenciados.
- Las interacciones más frecuentes entre ambos ocurren al reportar errores y entregar las correcciones.
- Muchas veces las interacciones son por correo electrónico o herramientas de gestión de pruebas de software.
- El equipo de Testing está integrado con el equipo de desarrollo. Es un solo equipo.
- Todos son responsables de la entrega de funcionalidad y de la calidad del producto.
- El rol del Tester enfocado a identificar errores y de desarrolladores a corregirlos se modifica, todos son igualmente responsables de entregar a tiempo y con calidad.
2.- El Testing es permanente, en etapas tempranas del proyecto y frecuente
En las metodologías predictivas de desarrollo de software, especialmente en el modelo de cascada, las pruebas de software son una fase del proyecto, que comienza una vez desarrollo termina su fase y entrega el producto.
Con frecuencia, ningún tipo de Testing se ha realizado hasta ese momento, ni siquiera las pruebas unitarias que deberían formar parte del proyecto, inclusive bajo enfoques predictivos.
En cambio, en las pruebas ágiles de software:
- Se ejecutan en iteraciones rápidas. El producto entregado al concluir debe poder desplegarse en ambiente de producción.
- Esto significa que el Testing debe ser permanente, inclusive cuando los desarrolladores no han terminado de integrar el producto.
- Para ello el Testing debe realizarse a nivel de unidad (Pruebas unitarias).
3.- El Testing se realiza en paralelo con el desarrollo de software
Las metodologías ágiles funciona con iteraciones rápidas, y la única forma de lograr entregar los productos es realizar las pruebas de software en paralelo con el desarrollo, esto significa:
- Probar el código fuente tan pronto es desarrollado.
- Al no estar integrado el producto, las pruebas se enfocan en el nivel unitario. Las historias de usuario se prueban tan pronto estén completadas.
- Esto evita la sobrecarga de trabajo en Testing al final de la iteración, como si ocurre cuando se trabaja con metodologías predictivas de desarrollo de software.
- Reduce el riesgo de sorpresas, los problemas son identificados y corregidos mientras se está construyendo el producto, lo cual es una mejor práctica en gestión de calidad.
Lectura recomendada
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Gestión práctica de proyectos con Scrum: Desarrollo de software ágil para el Scrum Master
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
5.- Los Testers están involucrados en todas las actividades del proyecto
En enfoques tradicionales, los Testers están activos durante la fase de pruebas de software solamente, de hecho, en la mayoría de los casos no comienzan con el proyecto desde la etapa de planificación, sino se integran semanas o días antes del comienzo de las pruebas de software.
A diferencia, en las pruebas ágiles de software, el tester necesita estar integrado desde la primera iteración. A lo largo de una iteración el Tester desempeña distintos roles, a saber:
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
4.- Los Testers asisten en las interacciones con el área de negocio
Bajo un enfoque de trabajo predictivo, el equipo de Testing y el de Analistas de negocio (Analistas funcionales) están completamente separados. Las interacciones con el área de negocio son manejadas por los Analistas de negocio y Gerentes de proyecto.
Cuando existen discrepancias entre las expectativas del cliente y el producto elaborado por el equipo, con frecuencia el marco de referencia suele ser la especificación de requerimientos, independientemente que las necesidades reales del usuario sean diferentes.
En las metodologías ágiles de desarrollo y pruebas de software, el rol del Testing se expande para asistir al dueño de producto en la gestión de requisitos, en aspectos como:
Bajo un enfoque de trabajo predictivo, el equipo de Testing y el de Analistas de negocio (Analistas funcionales) están completamente separados. Las interacciones con el área de negocio son manejadas por los Analistas de negocio y Gerentes de proyecto.
Cuando existen discrepancias entre las expectativas del cliente y el producto elaborado por el equipo, con frecuencia el marco de referencia suele ser la especificación de requerimientos, independientemente que las necesidades reales del usuario sean diferentes.
En las metodologías ágiles de desarrollo y pruebas de software, el rol del Testing se expande para asistir al dueño de producto en la gestión de requisitos, en aspectos como:
- Asistir en la elaboración de las historias de usuario. (La forma más difundida de documentar requerimientos de software en metodologías ágiles). Identificando errores y aspectos omitidos en su definición.
- Ayudar en la identificación de todos los criterios de aceptación asociados a las historias de usuario, basados en su conocimiento de las reglas de negocio y del producto.
- Por medio de interacción constante con el área de negocio, se trabaja en cumplir sus expectativas. Se favorecen la conversación e interacción en lugar de ceñirse a las especificaciones de requerimientos.
5.- Los Testers están involucrados en todas las actividades del proyecto
En enfoques tradicionales, los Testers están activos durante la fase de pruebas de software solamente, de hecho, en la mayoría de los casos no comienzan con el proyecto desde la etapa de planificación, sino se integran semanas o días antes del comienzo de las pruebas de software.
A diferencia, en las pruebas ágiles de software, el tester necesita estar integrado desde la primera iteración. A lo largo de una iteración el Tester desempeña distintos roles, a saber:
- Apoyar al dueño de producto en la elicitación de historias de usuario.
- Se integra a las reuniones para analizar la pila de producto (Product Backlog).
- En las sesiones de planificación de iteraciones, colabora en el desarrollo de estimaciones identificando funcionalidad y casos no considerados por los desarrolladores.
- Colabora en la planificación de la iteración (Sprint Planning) asegurando que se consideren adecuadamente las cargas de trabajo, y las estimaciones del trabajo de pruebas de software.
- En el día a día interactúa con desarrolladores, analistas de negocio y el dueño de producto, clarificando requerimientos, identificando problemas de diseño y ejecutando pruebas unitarias.
6.- El Tester necesita conocer a profundidad el funcionamiento interno del software
Bajo las metodologías de desarrollo de software en cascada, la mayor parte del Testing que se realiza es de caja negra, en el cual no se necesita tener un conocimiento interno de cómo funciona la aplicación.
A diferencia, en las pruebas ágiles de software el trabajo en paralelo y la velocidad de las pruebas son necesarias, por lo tanto es indispensable realizar también pruebas de caja blanca.
En un día típico, el Tester no solamente se limita a probar la aplicación desde su estación de trabajo, sino que debe realizar revisiones entre pares (Peer reviews) con los desarrolladores, inspeccionando el código e identificando problemas de forma temprana.
Para ello, los Testers necesitan tener un conocimiento interno del funcionamiento de la aplicación, en cuanto a tecnologías involucradas y lenguaje de programación.
7.- Depende en gran medida de la automatización de pruebas de software
Las metodologías ágiles funcionan con iteraciones rápidas, esto implica realizar pruebas complejas frecuentemente y con velocidad. Hacer esto de forma manual es imposible en la práctica, por lo cual son indispensables las herramientas de automatización de pruebas de software.
- Al desarrollar las historias, debe realizarse también la programación de las pruebas unitarias que la validen.
- También deben desarrollarse las pruebas automatizadas de integración.
- Las frecuentes integraciones de código requieren la ejecución repetida de pruebas de regresión.
- Debe evitarse el uso de Mocks (programas no reales que simulan respuestas), siempre que no sea indispensable.
- Existen muchas herramientas para realizar pruebas automatizadas, como por ejemplo Selenium, HP Quick Test y muchas otras.
8.- Debe existir equilibrio entre las pruebas de nueva funcionalidad y las pruebas de regresión
- En las pruebas ágiles de software, la gestión de calidad debe establecer un equilibrio entre las pruebas de nueva funcionalidad y las pruebas de regresión.
- Cuando las historias de usuario son completadas por los desarrolladores, el enfoque es en las pruebas de nueva funcionalidad, confirmando que las pruebas de aceptación funcionan.
- En otros momentos, en enfoque es en las pruebas de regresión, por ejemplo cuando se realizan integraciones de código a la fuente central.
- Las pruebas de regresión manuales deben realizare en casos borde o pruebas de comportamiento difíciles de automatizar. Las demás pruebas de regresión deben automatizarse en la medida de lo posible.
- Las pruebas de regresión deben ejecutarse al momento de realizar cada compilación de la fuente central.
Al haber aplicado las pruebas ágiles de software ¿Cuáles consideras que son las principales diferencias respecto al enfoque predictivo? ¿Cambia la forma de trabajar? ¿Cuál es el rol del Tester en las metodologías ágiles?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de pruebas de software?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Estoy de acuerdo en todo. Sólo hay un punto que me "chirría". Llamar a esas personas "testers". Creo que la palabra "tester" evoca en nuestras neuronas tiempos pasados. Es una palabra del modelo antiguo. El tester, como su nombre indica, testea. Así todo el equipo deberían ser testers, si quieren estar perfectamente integrados.
ResponderEliminarYo prefiero llamarlos Técnicos de QA, responsables de QA, o "QA's" a secas. Son responsables de asegurar la calidad, en cualquier etapa.