Alta calidad técnica mediante prácticas de pruebas ágiles

Todavía hacen falta pruebas manuales, ¡pero no de la forma que estás pensando!

Dan Radigan Dan Radigan

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.

To make matters worse, QA teams are traditionally rewarded according to how many bugs they find, which puts developers on the defensive. What if there was a better way for both developers and QA to reduce the number of bugs in the code while also eliminating those painful trade-offs project owners have to make? Wouldn't it create better all-around software?

Métete en las pruebas ágiles.

Pasar de métodos de prueba tradicionales a ágiles

El objetivo de un equipo de desarrollo ágil es entregar funcionalidades nuevas de calidad de una forma sostenible. Los equipos que se pasan a la agilidad suelen bregar con cómo incorporar el tiempo de pruebas a la velocidad ágil. Esta dificultad es legítima, pues los métodos tradicionales de pruebas simplemente no encajan en un contexto ágil. El ritmo de desarrollo requiere otro planteamiento para garantizar la calidad de las builds. En Atlassian, realizamos pruebas de manera ágil.  Examina detalladamente nuestro método de pruebas con Penny Wyatt, jefa superior 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.

Pro Tip:

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 generadas por script, 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 generadas por script.

Mantener la calidad entraña una mezcla de pruebas exploratorias y automatizadas. A medida que se desarrollan nuevas funcionalidades, 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 funcionalidad, 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?"