Si eres desarrollador o tester, la palabra ágil no es nada nuevo para ti. Pero si eres nuevo en esto y te preguntas qué es el testing ágil y qué significa en la práctica, no te quedará ninguna duda después de leer este artículo.
¿Qué es el testing ágil?
Las pruebas ágiles son una parte inseparable de la metodología de desarrollo ágil de software. En la metodología ágil, las pruebas se realizan de forma continua junto con el propio desarrollo. Es un esfuerzo mutuo de desarrolladores, probadores, gestores de proyectos y clientes para adaptar el producto a las necesidades del cliente.
A diferencia de la metodología en cascada, en la que las pruebas son una fase separada que se produce después de la fase de desarrollo, la metodología de pruebas ágiles implica que las pruebas empiezan al principio del proyecto y van de la mano del desarrollo, proporcionando una retroalimentación continua en el proceso de desarrollo.
Los probadores ya no son una unidad separada. Forman parte del equipo de desarrollo ágil de software y trabajan estrechamente con los desarrolladores durante todo el ciclo de vida del desarrollo ágil de software, lo que permite:
- Ahorrar tiempo y dinero
- Menos documentación
- Retroalimentación periódica
- Identificar los problemas con antelación
Entonces, ¿cuáles son las razones para elegir o no un proceso ágil? La mejor forma de responder es la lista de pros y contras.
Ventajas de la metodología ágil
- Flexibilidad
- Productividad
- Transparencia
- Alta calidad
- Adaptación regular a circunstancias cambiantes
- Mayor implicación y satisfacción del cliente
Desventajas de la metodología ágil
- No es adecuada para cualquier proyecto
- Difícil de implantar cuando los clientes siguen procesos o métodos rígidos
- Es difícil estimar el esfuerzo necesario al principio del ciclo de vida del desarrollo de software
- Falta de énfasis en el diseño y la documentación necesarios
- Sólo los desarrolladores senior pueden tomar el tipo de decisiones necesarias durante el proceso de desarrollo
Si decide adoptar las pruebas ágiles, también deberá conocer sus principios fundamentales.
Principios de las pruebas ágiles
- Las pruebas no son una fase separada, sino un proceso constante
- Las pruebas mejoran el producto a través de la retroalimentación constante
- En las pruebas pueden participar no sólo los probadores, sino también los desarrolladores
- Las pruebas se realizan de acuerdo con una lista de comprobación reutilizable, no con una documentación detallada
- Las pruebas se realizan en equipos autoorganizados
Todo ello para:
- Tener en cuenta los cambios en los requisitos, incluso en las pruebas más avanzadas
- Entregar un producto de software de alta calidad en un plazo breve
- Satisfacer al cliente con la entrega rápida de un producto de alta calidad
Pero antes de adherirse a cualquiera de ellos, tendrá que elegir el marco de pruebas ágil que mejor funcione con sus procesos y métodos de pruebas. Los más utilizados son Scrum y Kanban.
Scrum y Kanban: ¿Cuál es la diferencia?
Scrum es un enfoque en el que un equipo universal de especialistas trabaja en cada proyecto. También implica un propietario del producto y un scrum master:
- El propietario del producto conecta al equipo con el cliente y supervisa el desarrollo del proyecto.
- El scrum master ayuda al propietario del producto a organizar el proceso empresarial: celebra reuniones generales, resuelve los problemas cotidianos, motiva al equipo y supervisa el cumplimiento del enfoque scrum.
El enfoque Scrum divide el flujo de trabajo en sprints iguales. Son periodos que van de una semana a un mes, dependiendo del proyecto y del equipo. Una vez finalizado el sprint, las tareas completadas se pasan a producción y otras se transfieren a otro sprint.
Las tareas que se realizan durante el sprint no suelen cambiar: lo que se fijó para la implementación al comienzo del sprint debe realizarse a toda costa al final del sprint. Los sprints son muy fáciles de comparar, lo que permite gestionar la eficiencia del trabajo.
El enfoque Kanban consiste en equilibrar el trabajo de varios especialistas dentro del equipo y evitar la situación en la que los diseñadores trabajan durante días y los desarrolladores se quejan de la falta de nuevas tareas.
Todo el equipo es una unidad en Kanban. Aquí no hay propietario del producto ni scrum-master. El proceso de negocio no se divide en sprints universales, sino en etapas de realización de tareas específicas:
- Hacer
- Desarrollo
- Probar
- Despliegue
El principal indicador de eficacia en Kanban es el tiempo medio que se tarda en completar la tarea. La tarea pasa rápidamente – el equipo trabaja de forma productiva y armoniosa. La tarea se alarga: hay que pensar en qué fase y por qué se han producido retrasos y qué trabajo debe optimizarse.
Kanban le da más flexibilidad, lo que significa la frecuencia de cambio de prioridades. Si el desarrollador carga la tarea terminada y recibe comentarios de que no funciona como estaba previsto, obtiene nuevos requisitos en los que trabajar. Estas nuevas tareas suben de prioridad y el programador las realiza en primer lugar.
Para formar un sprint en Scrum, las tareas deben evaluarse en puntos de historia u horas. Sin dicha evaluación, será imposible formar un sprint, ya que se necesita saber si se conseguirá completar las tareas en un tiempo determinado. Una vez transcurrido ese tiempo, se obtienen las estadísticas de horas o puntos de historia que el equipo ha sido capaz de realizar en un sprint. Permite medir la velocidad de rendimiento del equipo en un sprint. Sabiendo esto, el gestor Scrum puede predecir dónde estará el equipo en el siguiente sprint.
Kanban no requiere evaluación. El concepto de «velocidad de trabajo en equipo» no existe: sólo se tiene en cuenta el tiempo medio necesario para completar una unidad de trabajo.
Así, en Scrum, el objetivo es terminar el sprint, en Kanban – la tarea.
Para mantener todo en orden y bajo control, tanto Scrum como Kanban utilizan tableros que visualizan las tareas y la fase en la que se encuentran.
Las tareas en los tableros se dividen según el principio:
- Por hacer
- En curso
- Hecho
La única diferencia es que el tablero Scrum divide las tareas en sprints, y todas las tareas que están en un sprint en particular tienen que estar «Hechas» cuando este Sprint termine.
¿Recapitulamos ahora?
Para que veas cómo funciona en la práctica, veamos algunos ejemplos.
Pruebas ágiles en QAwerk
Siendo una empresa de pruebas de software, podemos mostrar nuestros propios ejemplos de cómo la metodología ágil impacta en el flujo de trabajo de un proyecto en particular.
Unfold
Unfold es una aplicación para iOS y Android que permite crear historias con fotos y vídeos utilizando diferentes plantillas.
En este proyecto, el desarrollo se realiza en el lado del cliente. El trabajo está estructurado de tal forma que las actualizaciones de las versiones tanto de iOS como de Android son constantes: pequeñas ediciones, cambios de diseño, adición de funcionalidades de suscripción, adición de nuevas colecciones de plantillas que a menudo se añaden en colaboración con estrellas (Miley Cyrus), películas (The Sun is Also a Star), grandes eventos (Billboard Music Awards), marcas de ropa (Tommy Hilfiger).
El cliente no comparte con nosotros los planes de desarrollo ni la documentación. Pero esto es lo que el proceso ágil de pruebas nos permite hacer cuando trabajamos en este proyecto:
- Siempre estamos listos para probar la nueva versión en todos los tipos de dispositivos que tenemos
- Nos comunicamos con los desarrolladores, realizamos regresiones frecuentes de los errores que se corregirán en la versión actual hasta que se mejore hasta el nivel en que se pueda publicar
- También trabajamos con los comentarios de los usuarios en las tiendas de aplicaciones (Google, Apple) y recopilamos los comentarios de los usuarios para reproducir errores, iniciar informes y comunicarnos con los desarrolladores
- Una vez trabajamos en equipo durante el fin de semana para ayudar a probar una actualización importante: añadir suscripciones a la aplicación
Conclusión
Independientemente de la metodología de pruebas ágiles que se utilice, ambas permiten la detección temprana de errores, lo que reduce el coste de su corrección. También es un enfoque centrado en el cliente que permite ofrecer un producto de alta calidad en un plazo relativamente corto.
