Ágil: nada tan malo que no se pueda poner en funcionamiento ni tan bueno que no se pueda mejorar

Ágil: nada tan malo que no se pueda poner en funcionamiento ni tan bueno que no se pueda mejorar

March 30, 2021

Este sitio web utiliza cookies

Lisiane es Tester de Sistemas desde hace casi dos años y utiliza metodologías ágiles para realizar su trabajo. Hoy comparte con nosotros su perspectiva profesional sobre este tema, cada vez más discutido en el área de IT.

“De hecho, ¿qué son las metodologías ágiles? ¿Por qué se utilizan de forma tan significativa y cómo afectan al área de pruebas de software? Hablaré un poco sobre mi experiencia como tester de software e intentaré responder estas preguntas.

Metodologías ágiles – ¿Qué son?

Muchos de nosotros, dentro del área de Tecnologías de la Información, ya trabajamos con las denominadas “Metodologías Ágiles” y especialmente aquellas involucradas en los ciclos de vida del desarrollo de software. Las metodologías ágiles, también conocidas simplemente como “agile”, están directamente relacionadas con la forma en que desarrollamos software. Aunque el término ahora se usa ampliamente, una simple motivación subyace a su existencia: hacer lo que hacemos de la mejor manera posible. Por lo tanto, el conocido Manifiesto para el desarrollo de software ágil comprende los siguientes cuatro principios básicos:

Individuos e interacciones sobre procesos y herramientas;

Software de trabajo sobre documentación completa;

Colaboración con el cliente sobre la negociación de contratos

Responde al cambio sobre el siguiente plan

Esto no quiere decir que el resto de funcionalidades ya no sean importantes, sin embargo, el foco debe estar en enfatizar la eficiencia de la producción de software y así, la interacción, la funcionalidad, la colaboración y la adaptabilidad terminan siendo más significativas en la medida en que agilizan los procesos sin perder calidad. .

El uso significativo de metodologías ágiles, ¿por qué?

Si bien el uso de metodologías ágiles se ha popularizado y crece constantemente, podemos percibir que en décadas pasadas se han hecho movimientos para encontrar mejores técnicas para el desarrollo de software. El problema principal es que, en la era tecnológica actual de amplias comunicaciones y de amplio alcance, hemos estado valorando la eficiencia y la velocidad del desarrollo de software con una intensidad creciente. Vivimos en la era del “clic”, es decir, al hacer clic en un botón podemos comprar un producto o contratar un servicio. En consecuencia, esto provocó la necesidad de desarrollar software lo más rápido posible.

Por otro lado, muchas empresas todavía utilizan el llamado “modelo en cascada”, que dictaba las pautas del ciclo de vida del desarrollo de software antes de que las metodologías ágiles se hicieran populares. En términos simples, podemos imaginar el desarrollo utilizando un modelo en cascada como escalera, donde solo podemos subir al siguiente paso después de haber subido el anterior. Si bien tiene varios beneficios, concretamente por su solidez y riqueza en los temas más específicos, este modelo termina obstaculizando el flujo de procesos, dificultando enormemente a los involucrados a enfrentar cualquier tipo de evento inesperado. Además, el tiempo empleado en la fase de planificación es extremadamente grande ya que requiere un análisis muy detallado, prediciendo cada fase del ciclo. Comparando el modelo actual con el anterior, podemos entender la razón por la que se prefieren metodologías ágiles.

¿Cómo impactan las metodologías ágiles en las pruebas de software?

Las metodologías ágiles cuentan con herramientas y principios útiles para cualquier área, desde el Marketing hasta los Recursos Humanos, pasando por el diseño. Se adaptan a las particularidades de cada sector y permiten siempre innovar y mejorar la eficiencia de los procesos. Por lo tanto, es natural que el área de pruebas de software también se vea afectada en muchos casos, especialmente considerando su estrecha relación con el ciclo de vida del desarrollo de software, por lo que no es raro escuchar el término “pruebas ágiles” relacionado precisamente con este ciclo. Al tratarse de una nueva forma de actuar en los procesos de desarrollo, también es natural que existan variaciones en la forma de implementar las pruebas ágiles, que variarán según la organización de sectores, proyectos y equipos dentro de una empresa.

En la práctica, ¿cómo son las pruebas ágiles?

Compartiendo un poco de mi propia experiencia, puedo ejemplificar un tipo de implementación. Para empezar, imaginemos una empresa tradicional, aunque adopte metodologías ágiles. Siguiendo el flujo de trabajo habitual, se realiza una reunión para definir qué se desarrollará, los requisitos necesarios y cómo se fragmentarán las tareas. Los programadores desarrollarán sus responsabilidades por separado y en muchos casos, lo que se ha desarrollado es un fragmento apenas perceptible a nivel de código. Será solo después del desarrollo de todas las tareas y con el producto final listo para la entrega, cuando los testers podrán comenzar a validar lo desarrollado. Después de la prueba, el producto se entrega al cliente y el proceso se repite con un nuevo producto.

Sin embargo, supongamos que el probador encontró un problema con el producto: había un botón que debería existir, pero no estaba especificado ni desarrollado. Dentro de este flujo, no hay más tiempo para hablar con el cliente, ni con el analista, para especificar, desarrollar y probar nuevamente. Incluso en una metodología ágil, el proceso termina en un molde, debido a las restricciones impuestas y las divisiones creadas en el trabajo de cada una de las partes involucradas. A decir verdad, en la mayoría de los casos, este flujo funciona bien y problemas como este pueden resolverse fácilmente con el cliente, con el compromiso del equipo de entregar la funcionalidad en el siguiente producto. Sin embargo, partiendo del principio de que siempre podemos mejorar y ofrecer una mayor eficiencia, imagina la implementación de pruebas ágiles en este proceso.

En comparación con el proceso descrito anteriormente, imaginemos que en lugar de esperar a que el producto final inicie las pruebas, el tester puede simplemente verificar inmediatamente la tarea realizada por el programador, prácticamente en tiempo real. De esta manera, la tarea del programador no recibirá el estado de “completada” hasta que también sea validada por el tester. Así, una vez finalizadas todas las tareas y el producto listo para la entrega, se inicia una nueva fase de prueba, en la que ya se han validado las tareas, quedando solo una prueba de integración final por realizar.

Ahora, retrocedemos e imaginamos la situación en la que no se incluyó en el desarrollo un botón importante para el funcionamiento del producto. Al identificar el problema, el evaluador puede iniciar rápidamente un diálogo con el analista y los programadores, incluir la tarea en el flujo de desarrollo y si es necesario, realinear las prioridades resolviendo el asunto. En esta forma de trabajo, las partes involucradas no actúan individualmente, sino en conjunto. El probador siempre está al tanto de los detalles y los requisitos proporcionados por el analista, y el programador a su vez, conoce lo que ya ha sido validado por el tester, por lo que la comunicación con el cliente es transparente.

De ahí que, recordando los principios rectores de los procesos ágiles, se hace énfasis en las interacciones de las partes involucradas, entregamos un producto funcional y de calidad con el acuerdo del cliente y a todo ello se le brinda una alta adaptabilidad a los imprevistos que son intrínsecos al proceso de desarrollo de software.

¿Qué podemos concluir?

Hay casos en los que la implementación de tests ágiles es muy positiva pero, con mi experiencia profesional, puedo identificar fácilmente algunos aspectos positivos y negativos:

Negativo:

– Por lo general, es necesario contar con un entorno de pruebas concreto, lo que exige un tiempo específico dedicado exclusivamente al mantenimiento de este entorno;

– Requiere testers con un mayor nivel de conocimientos en programación, ya que las pruebas se suelen realizar a nivel de código;

– Requiere un alto nivel de integración entre analistas, programadores, testers y todas las demás partes involucradas en el proyecto, incluido el cliente que dependiendo de la dimensión del equipo/proyecto, esto no siempre es fácil de lograr.

Positivo:

– Al implementarse correctamente, una prueba ágil generalmente agrega calidad al producto entregado;

– La información fluye de manera más transversal entre las partes involucradas en el proyecto, lo que reduce el número de errores por falta de comunicación;

– El número de errores abiertos es drásticamente menor, ya que se informan y resuelven aún en la fase de desarrollo;

– Se incrementa el conocimiento técnico de los testers ya que se requiere acceso a los proyectos.

Considerando todo lo anterior, podemos ver que en metodologías ágiles o pruebas ágiles, no existe un modelo mágico que resuelva todos nuestros problemas. ¡Esto es un hecho! Pero como sabemos, cada proyecto es único y tiene sus propias características y particularidades. Cuando hablamos de metodologías ágiles, lo más importante no es seguir cada paso o principio “al pie de la letra”, sino buscar la mejora continua del proceso de trabajo. “Nada tan malo que no se pueda poner en funcionamiento ni tan bueno que no se pueda mejorar ”.

Lisiane Engel

Tester de Sistemas – PrimeIT