La gestión de proyectos en cascada divide el desarrollo y las pruebas en dos pasos distintos: los desarrolladores crean una funcionalidad y luego se la "lanzan" al equipo de control de calidad (QA, por sus siglas en inglés) para que realicen las pruebas. El equipo de control de calidad escribe y ejecuta los planes de pruebas en detalle. También liman los defectos al verificar minuciosamente si hay regresiones en las funcionalidades existentes que el nuevo trabajo podría haber provocado.
Muchos equipos que utilizan estas cascadas u otros modelos tradicionales de pruebas observan que, según crece el producto, la cantidad de pruebas aumenta exponencialmente, y el control de calidad lucha invariablemente por seguir el ritmo. Los propietarios de proyectos se enfrentan a una inoportuna elección: retrasar la publicación o escatimar en pruebas. (Adivina cuál de las dos opciones gana el 99 % de las veces). Mientras tanto, el desarrollo ha pasado a otra cosa. Así pues, no solo aumenta la deuda técnica, sino que tratar cada defecto requiere un costoso cambio de contexto entre dos partes de la base de código. El colmo.
Para empeorar aún más las cosas, normalmente se recompensa a los equipos de control de calidad por los errores que hayan encontrado, con lo que los desarrolladores se ponen a la defensiva. ¿Y si hubiera una forma mejor para que tanto el equipo de desarrollo como el de control de calidad redujeran el número de errores de código, a la vez que se eliminan esas amargas concesiones que tienen que hacer los propietarios del proyecto? ¿No se crearía un software completo mejor?
Pasar de métodos de prueba tradicionales a ágiles
Los equipos ágiles y de DevOps tienen como objetivo entregar funciones nuevas de calidad de forma sostenible. Sin embargo, las metodologías de pruebas tradicionales no encajan en un marco ágil o DevOps. El ritmo de desarrollo requiere otro enfoque para garantizar la calidad de las compilaciones. En Atlassian, realizamos pruebas siguiendo la metodología ágil. Analiza detenidamente nuestro método de pruebas con Penny Wyatt, responsable sénior del equipo de control de calidad de Jira Software.
De forma muy similar al cálculo de la deuda de una tarjeta de crédito, comienza con cierto dolor, pero rápidamente se agrava... y debilita la agilidad analítica del equipo. Para hacer frente a la multiplicación de la deuda técnica, en Atlassian capacitamos a nuestros desarrolladores para que sean unos campeones en materia de calidad (bueno, no: esperamos que lo sean). Creemos que los desarrolladores aportan habilidades fundamentales para fomentar la calidad del producto:
- Los desarrolladores son muy buenos en resolver problemas de código.
- Los desarrolladores que escriben sus propias pruebas están más comprometidos con solucionarlos cuando fracasan.
- Los desarrolladores que entienden los requisitos de la funcionalidad y sus implicaciones de pruebas suelen escribir mejor código.
Creemos que cada historia de usuario del backlog requiere tanto código de la funcionalidad como código de la prueba automatizada. Aunque algunos equipos asignan el código de la funcionalidad a los desarrolladores mientras el equipo de pruebas se encarga de las pruebas automatizadas, pensamos que es más efectivo que un solo técnico entregue todo el conjunto.
Trata los bugs de funcionalidades nuevas y las regresiones de funcionalidades existentes de forma distinta. Si surge un error durante el desarrollo, dedica un momento a comprender el fallo, arréglalo y sigue adelante. Si aparece una regresión (es decir, algo que antes funcionaba ha dejado de funcionar), es probable que vuelva a aparecer. Crea una prueba automatizada para impedir que la regresión reaparezca en el futuro.
Este modelo no quiere decir que los desarrolladores trabajen solos. Es importante contar también con técnicos de control de calidad en el equipo. El control de calidad ofrece una perspectiva importante del desarrollo de una funcionalidad, y los buenos técnicos de control de calidad saben dónde se suelen esconder los errores y pueden advertir a los desarrolladores de probables "te pillé".
Pruebas exploratorias con un toque humano
En nuestros equipos de desarrollo, los miembros de control de calidad se unen a los desarrolladores para llevar a cabo las pruebas exploratorias, una valiosa práctica durante el desarrollo para defenderse de más errores graves. De forma muy similar a la revisión del código, hemos visto cómo se transmiten los conocimientos de pruebas al equipo de desarrollo por ese motivo. Cuando los desarrolladores se convierten en mejores evaluadores, se entrega mejor código la primera vez.
¿Pero las pruebas exploratorias no son manuales? Pues no. Al menos no en el mismo sentido que las pruebas manuales de regresiones. Las pruebas exploratorias son un método de prueba basado en los riesgos y de pensamiento crítico en el que el evaluador emplea sus conocimientos de riesgos, detalles de implementación y necesidades del cliente. Saber estas cosas con anterioridad en los procesos de prueba permite que el desarrollador o el técnico de control de calidad encuentre las incidencias rápidamente y de forma exhaustiva, sin necesidad de disponer de casos de pruebas con guion, planes de prueba detallados ni requisitos. Pensamos que son mucho más efectivas que las pruebas manuales tradicionales, ya que podemos devolver las ideas de las sesiones de pruebas exploratorias al código original y las pruebas automatizadas. Las pruebas exploratorias también nos enseñan la experiencia de utilizar una funcionalidad de un modo que no consiguen las pruebas con guion.
Mantener la calidad entraña una mezcla de pruebas exploratorias y automatizadas. A medida que se desarrollan nuevas funciones, las pruebas exploratorias garantizan que el código nuevo cumpla las normas de calidad en un sentido más amplio que solo con las pruebas automatizadas. Esto incluye la facilidad de uso, un diseño agradable a la vista y una utilidad general de la función, aparte de las sólidas protecciones contra regresiones que proporcionan las pruebas automatizadas.
Cambiar cuesta, cuesta mucho
Os dejo con una anécdota personal que resume perfectamente mi trayectoria con las pruebas ágiles. Recuerdo que al principio de mi carrera estuve gestionando un equipo técnico que se resistía firmemente a escribir pruebas automatizadas, porque era "trabajo de control de calidad". Después de varias iteraciones de código erróneo y de oír todos los motivos por los que las pruebas automatizadas retrasarían al equipo, me puse firme: había que realizar pruebas automatizadas en todo el código nuevo.
Tras una sola iteración, el código empezó a mejorar. Y resulta que el desarrollador que estaba más rotundamente en contra de escribir pruebas fue el que se empezó a poner en marcha cuando una prueba fallaba. Durante las iteraciones siguientes, las pruebas automatizadas se incrementaron, escalaron entre navegadores y mejoraron el espíritu de desarrollo. Las funcionalidades tardaban más en salir, claro. Pero los errores y los repasos disminuyeron drásticamente, con lo que al final nos ahorraba muchísimo tiempo.
Los cambios no suelen ser fáciles. Pero, como la mayoría de cosas que valen la pena, si te arremangas y creas patrones nuevos para ti mismo, solo te quedará esta pregunta: "¿Por qué no lo había hecho antes?"
