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
Buscar temas

La gestión de proyectos en cascada divide el desarrollo y las pruebas en dos pasos distintos: los desarrolladores compilan una función y luego se la "lanzan" al equipo de control de calidad para que realicen las pruebas. El equipo de control de calidad escribe y ejecuta los planes de pruebas en detalle. Asimismo, liman los defectos al verificar minuciosamente si hay regresiones en las funciones existentes que el nuevo trabajo podría haber provocado.

Muchos equipos que utilizan estos modelos de prueba en cascada u otros modelos tradicionales creen que, según crece el producto, la cantidad de pruebas aumenta de manera exponencial, y el control de calidad lucha invariablemente por seguir el ritmo. Los propietarios del proyecto se enfrentan a una elección incómoda: 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 abordar 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?

Pásate a las pruebas ágiles.

Pasar de métodos de prueba tradicionales a ágiles

El objetivo de un equipo de desarrollo ágil es entregar funciones nuevas de calidad de una forma sostenible. Los equipos que se pasan a la metodología ágil suelen tener dificultades con cómo incorporar el tiempo de pruebas a la velocidad que requiere esta metodología. 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 cada compilación. 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 solucionarlas cuando fallan.
  • Los desarrolladores que entienden los requisitos de la función y sus implicaciones de pruebas suelen escribir mejor código.

Creemos que cada historia de usuario del backlog requiere tanto código de la función como código de la prueba automatizada. Aunque algunos equipos asignan el código de la función a los desarrolladores mientras el equipo de pruebas se encarga de las pruebas automatizadas, pensamos que es más eficaz que un solo ingeniero entregue todo el conjunto.

Consejo de experto:

Trata los errores de funciones nuevas y las regresiones de funciones 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 ingenieros de control de calidad en el equipo. El control de calidad ofrece una perspectiva importante del desarrollo de una función, y los buenos ingenieros de control de calidad saben dónde se suelen esconder los errores y pueden advertir a los desarrolladores de probables formas de detectarlos.

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 errores más 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 a la primera.

¿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 ingeniero 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 eficaces que las pruebas manuales tradicionales, ya que podemos volver a aplicar información 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 función 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 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 de ingenieros que se resistía firmemente a escribir pruebas automatizadas, porque era "trabajo de control de calidad". Después de varias iteraciones de código con errores 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 funciones tardaban más en salir, claro. Pero los errores y las repeticiones del trabajo disminuyeron drásticamente, lo que al final nos ahorró muchísimo tiempo.

Los cambios no suelen ser fáciles. Sin embargo, como la mayoría de cosas que valen la pena, si te arremangas y creas patrones nuevos para ti mismo, solo te quedará hacerte esta pregunta: "¿Por qué no lo había hecho antes?"

A continuación
Incident response