Un camino hacia mejores pruebas ágiles

El Informe de calidad mundial anual creado por Capgemini muestra que el 42% de los encuestados mencionan la "falta de experiencia profesional en pruebas" como un desafío al aplicar las pruebas al desarrollo Agile. Si bien la llegada de Agile ha traído una mayor velocidad de iteraciones para el desarrollo de software, en algunos casos, esto se ha producido a costa de la calidad.

La competencia feroz presiona a los equipos para que entreguen constantemente nuevas actualizaciones de productos, pero esto a veces tiene su propio costo, incluida la disminución de la atención hacia las pruebas. Algunos, como Rob Mason, van más allá y argumentan que Agile está acabando con las pruebas de software. Recientemente, Facebook cambió su lema de “muévete rápido y rompe cosas” a “muévete rápido con una infraestructura estable” en un intento de resolver las tentaciones de sacrificar la calidad.

Entonces, ¿cómo se pueden integrar mejor las pruebas en el nuevo mundo del desarrollo de software Agile? Pruebas ágiles.

Las pruebas tradicionales son bastante engorrosas y dependen de mucha documentación. Las pruebas ágiles son un enfoque del proceso de prueba que imita los principios del desarrollo de software ágil mediante el cual:

• Las pruebas se realizan con mucha más frecuencia,
• Las pruebas se basan menos en la documentación y más en la colaboración de los miembros del equipo, y
• Algunas actividades de prueba son realizadas no solo por probadores sino también por desarrolladores.

En los últimos siete años, hice la transición de muchos equipos a las pruebas Agile y trabajé codo a codo con los probadores para ayudar a que sus procesos se adaptaran a la nueva metodología. En este artículo, compartiré algunos de los consejos más impactantes que he aprendido a lo largo de mi camino hacia mejores pruebas Agile. Si bien es natural que haya fricción entre la velocidad y la calidad dentro de las prácticas ágiles, este artículo cubrirá algunas técnicas que se pueden usar para aumentar la calidad de las pruebas sin comprometer la agilidad. La mayoría de las sugerencias descritas aquí requerirán la participación del equipo, por lo que será beneficioso que tanto los desarrolladores como los evaluadores participen en la planificación.

Formalizar un proceso de ciclo de prueba de lanzamiento

Un problema con las pruebas es la ausencia del ciclo de prueba de lanzamiento, la falta de un cronograma de lanzamiento o las solicitudes de prueba irregulares. Las solicitudes de prueba a pedido dificultan el proceso de control de calidad, especialmente si los probadores manejan múltiples proyectos.

Muchos equipos solo hacen una compilación después de cada sprint, lo que no es ideal para proyectos Agile. Pasar a lanzamientos una vez a la semana podría ser beneficioso, pasando gradualmente a múltiples compilaciones por semana. Idealmente, las compilaciones de desarrollo y las pruebas deben realizarse a diario, lo que significa que los desarrolladores insertan el código en el repositorio todos los días y las compilaciones están programadas para ejecutarse en un momento específico. Para llevar esto un paso más allá, los desarrolladores podrían implementar código nuevo bajo demanda. Para implementar esto, los equipos pueden emplear un proceso de integración continua y despliegue continuo (CI/CD). CI/CD limita la posibilidad de una compilación fallida el día de un lanzamiento principal.

Cuando se combinan CI/CD y automatización de pruebas, es posible la detección temprana de errores críticos, lo que permite a los desarrolladores tener tiempo suficiente para corregir errores críticos antes del lanzamiento programado del cliente. Uno de los principios de Agile establece que el software funcional es la principal medida de progreso. En este contexto, un ciclo de lanzamiento formalizado hace que el proceso de prueba sea más ágil.

Empodere a los probadores con herramientas de implementación

Uno de los puntos de fricción comunes para las pruebas es implementar el código en un entorno de prueba. Este proceso depende de la infraestructura técnica que su equipo no pueda afectar. Sin embargo, si hay cierta flexibilidad, se pueden crear herramientas para personas no técnicas, como probadores o gerentes de proyectos, que les permitan implementar el código base actualizado para probarse a sí mismos.

Por ejemplo, en uno de mis equipos, usamos Git para el control de versiones y Slack para la comunicación. Los desarrolladores crearon un Slackbot que tenía acceso a Git, scripts de implementación y una máquina virtual. Los probadores pudieron hacer ping al bot con un nombre de rama adquirido de GitHub o Jira y tenerlo implementado en un entorno de prueba.

Esta configuración liberó mucho tiempo para los desarrolladores al tiempo que redujo el desperdicio de comunicación y las interrupciones constantes cuando los evaluadores tenían que pedirles a los desarrolladores que implementaran una rama para realizar pruebas.

Experimente con TDD y ATDD

El desarrollo basado en pruebas (TDD) es un tipo de proceso de desarrollo de software que pone mucho énfasis en la calidad. Tradicionalmente, un desarrollador escribe el código y luego alguien lo prueba e informa si se encuentran errores. En TDD, los desarrolladores escriben pruebas unitarias antes incluso de escribir cualquier código que complete una historia de usuario. Las pruebas inicialmente fallan hasta que el desarrollador escribe la cantidad mínima de código para pasar las pruebas. Después de eso, el código se refactoriza para cumplir con los requisitos de calidad del equipo.

El desarrollo basado en pruebas de aceptación (ATDD) sigue una lógica similar a TDD pero, como su nombre lo indica, se centra en las pruebas de aceptación. En este caso, las pruebas de aceptación se crean antes del desarrollo en colaboración con los desarrolladores, evaluadores y el solicitante (cliente, propietario del producto, analista comercial, etc.). Estas pruebas ayudan a todos los miembros del equipo a comprender los requisitos del cliente antes de escribir cualquier código.

Técnicas como TDD y ATDD hacen que las pruebas sean más ágiles al mover los procedimientos de prueba a las primeras etapas del ciclo de vida del desarrollo. Al escribir escenarios de prueba desde el principio, los desarrolladores deben comprender muy bien los requisitos. Esto minimiza la creación de código innecesario y también resuelve cualquier incertidumbre del producto al comienzo del ciclo de desarrollo. Cuando las preguntas o los conflictos del producto surgen solo en las etapas posteriores, aumentan el tiempo y los costos de desarrollo.

Descubra ineficiencias mediante el seguimiento del movimiento de tarjetas de tareas

En uno de mis equipos, teníamos un desarrollador que era extremadamente rápido, especialmente con funciones pequeñas. Obtenía muchos comentarios durante la revisión del código, pero nuestro maestro de Scrum y yo descartamos eso como falta de experiencia. Sin embargo, a medida que comenzó a codificar funciones más complejas, los problemas se hicieron más evidentes. Había desarrollado un patrón de pasar el código a prueba antes de que estuviera completamente listo. Este patrón generalmente se desarrolla cuando hay una falta de transparencia en el proceso de desarrollo, por ejemplo, no está claro cuánto tiempo dedican las diferentes personas a una tarea determinada.

A veces, los desarrolladores apresuran su trabajo en un intento de sacar las funciones lo antes posible y "tercerizar" la calidad a los probadores. Tal configuración solo mueve el cuello de botella más abajo en el sprint. La garantía de calidad (QA) es la red de seguridad más importante que tiene el equipo, pero eso puede significar que la existencia de QA les da a los desarrolladores la capacidad de renunciar a las consideraciones de calidad.

Muchas herramientas modernas de gestión de proyectos tienen la capacidad de rastrear el movimiento de las tarjetas de tareas en un tablero Scrum o Kanban. En nuestro caso, usamos Jira para analizar qué pasaba con las tareas del desarrollador en cuestión e hicimos comparaciones con otros desarrolladores del equipo. Descubrimos que:

• Sus tareas pasaron casi el doble de tiempo en la columna de prueba de nuestro tablero;
• Sus tareas serían devueltas con mucha más frecuencia por el control de calidad para una segunda o tercera ronda de arreglos.

Entonces, además de que los probadores tenían que dedicar más tiempo a sus tareas, también tenían que hacerlo varias veces. Nuestro proceso opaco hizo que pareciera que el desarrollador fue muy rápido; sin embargo, eso resultó ser falso cuando tomamos en cuenta el tiempo de prueba. Mover las historias de los usuarios de un lado a otro obviamente no es un enfoque esbelto.

Para resolver esto, comenzamos por tener una discusión honesta con este desarrollador. En nuestro caso, simplemente no era consciente de lo perjudicial que era su patrón de trabajo. Fue solo la forma en que se acostumbró a trabajar en su empresa anterior, que tenía requisitos de calidad más bajos y un grupo de probadores más grande. Después de nuestra conversación y con la ayuda de algunas sesiones de programación en pareja con nuestro maestro Scrum, gradualmente hizo la transición a un enfoque de desarrollo de mayor calidad. Debido a sus habilidades de codificación rápida, todavía tenía un alto rendimiento, pero el "desperdicio" eliminado del proceso de control de calidad hizo que todo el proceso de prueba fuera mucho más ágil.

Agregar automatización de pruebas al conjunto de aptitudes del equipo de control de calidad

Las pruebas en proyectos no ágiles implican actividades como el análisis de pruebas, el diseño de pruebas y la ejecución de pruebas. Estas actividades son secuenciales y requieren una extensa documentación. Cuando una empresa hace la transición a Agile, la mayoría de las veces, la transición se enfoca principalmente en los desarrolladores y no tanto en los evaluadores. Dejan de crear una documentación extensa (un pilar de las pruebas tradicionales) pero continúan realizando pruebas manuales. Sin embargo, las pruebas manuales son lentas y, por lo general, no pueden hacer frente a los rápidos ciclos de retroalimentación de Agile.

La automatización de pruebas es una solución popular a este problema. Las pruebas automatizadas facilitan mucho la prueba de características nuevas y pequeñas, ya que el código de prueba puede ejecutarse en segundo plano mientras los desarrolladores y evaluadores se concentran en otras tareas. Además, como las pruebas se ejecutan automáticamente, la cobertura de las pruebas puede ser mucho mayor en comparación con los esfuerzos de las pruebas manuales.

Las pruebas automatizadas son fragmentos de código de software similares al código base que se está probando. Esto significa que las personas que escriben pruebas automatizadas necesitarán habilidades técnicas para tener éxito. Hay muchas variaciones diferentes de cómo se implementan las pruebas automatizadas en diferentes equipos. A veces, los propios desarrolladores asumen el papel de evaluadores y aumentan la base de código de prueba con cada característica nueva. En otros equipos, los probadores manuales aprenden a usar herramientas de automatización de pruebas o se contrata a un probador técnico experimentado para automatizar el proceso de prueba. Cualquiera que sea el camino que tome el equipo, la automatización conduce a pruebas mucho más ágiles.

Administrar las prioridades de las pruebas

Con el desarrollo de software no ágil, los evaluadores generalmente se asignan por proyecto. Sin embargo, con la llegada de Agile y Scrum, se ha vuelto común que los mismos profesionales de control de calidad operen en múltiples proyectos. Esta responsabilidad superpuesta puede crear conflictos en los cronogramas y hacer que los probadores pierdan ceremonias críticas cuando un probador prioriza la prueba de lanzamiento de un equipo sobre la sesión de planificación de sprint de otro.

La razón por la que los probadores a veces trabajan en múltiples proyectos es obvia: rara vez hay un flujo constante de tareas para que las pruebas desempeñen un rol de tiempo completo. Por lo tanto, puede ser difícil convencer a las partes interesadas de que tengan un recurso de prueba dedicado asignado a un equipo. Sin embargo, hay algunas tareas razonables que un probador puede hacer para llenar su tiempo de inactividad cuando no participa en actividades de prueba.

Atención al cliente

Una posible configuración es hacer que el evaluador dedique su tiempo de inactividad del sprint a ayudar al equipo de atención al cliente. Al enfrentar constantemente los problemas que tienen los clientes, el probador tiene una mejor comprensión de la experiencia del usuario y cómo mejorarla. Pueden contribuir a las discusiones durante las sesiones de planificación. Además, se vuelven más atentos durante sus actividades de prueba, ya que están mejor familiarizados con la forma en que los clientes usan realmente su software.

Gestión de productos

Otra técnica para administrar las prioridades de los evaluadores es esencialmente convertirlos en gerentes de productos junior que realizan pruebas manuales. Esta también es una solución viable para llenar el tiempo libre de un probador porque los gerentes de producto junior pasan mucho tiempo creando requisitos para las historias de usuario y, por lo tanto, tienen un conocimiento profundo de la mayoría de las tareas.

Automatización de pruebas

Como hemos discutido anteriormente, las pruebas manuales a menudo son inferiores a la automatización. En este contexto, el impulso de la automatización se puede combinar con tener un probador que dedique toda su atención al equipo y utilice su tiempo libre para aprender a trabajar con herramientas de automatización de pruebas como Selenium.

Resumen: pruebas ágiles de calidad

Hacer que las pruebas sean más ágiles es una inevitabilidad a la que se enfrentan ahora muchos equipos de desarrollo de software. Sin embargo, la calidad no debe verse comprometida al adoptar una mentalidad de "prueba tan rápido como puedas". Es imperativo que una transición ágil incluya un cambio a las pruebas ágiles, y hay algunas formas de lograrlo:

• Formalizar un proceso de ciclo de prueba de lanzamiento.
• Capacite a los evaluadores con herramientas de implementación.
• Experimente con el desarrollo basado en pruebas y el desarrollo basado en pruebas de aceptación.
• Descubra ineficiencias mediante el seguimiento del movimiento de tarjetas de tareas.
• Agregue la automatización de pruebas al conjunto de habilidades del equipo de control de calidad.
• Administrar las prioridades de los evaluadores.

Cada año, el software mejora y las expectativas de los usuarios aumentan. Además, a medida que los clientes se acostumbran a los productos de alta calidad de las mejores marcas de software como Google, Apple y Facebook, estas expectativas también se transfieren a otros productos de software. Por lo tanto, es probable que el énfasis en la calidad sea aún más importante en los próximos años. Estas mejoras en el proceso de pruebas y desarrollo general pueden hacer que las pruebas sean más ágiles y garantizar un alto nivel de calidad del producto.