¿Debo ejecutar manualmente una prueba de regresión completa después de corregir un bug?

🇺🇸 English version here 🇺🇸

Recientemente, discutí con un grupo de amigos QA sobre si es obligatorio ejecutar una regresión completa manualmente después de recibir una corrección de un bug. En resumen, es necesario solo si tu equipo necesita madurar en ingeniería de software. Y no, esta no es una respuesta sarcástica. Permíteme explicar por qué.

La calidad debe verse como un resultado en lugar de un proceso. Un proceso es algo que haces en un momento definido y, en el desarrollo de software, la calidad a menudo se ve como algo que se hace al final del ciclo de desarrollo (SDLC: Software Development Life Cycle). Sin embargo, la calidad es la suma de muchas decisiones y acciones implementadas a lo largo del proceso de desarrollo. Esto es lo que realmente es la ingeniería de software, no solo la codificación. Se trata de hacer que el producto sea duradero y de facilitar procesos de ingeniería futuros como la mantenibilidad y la extensibilidad.

Corrección de bugs mediante mejores prácticas de ingeniería

Antes de comenzar, nunca debemos olvidar que, como ingenieros de software, debemos seguir la regla de los Boy Scouts: «Siempre deja el campamento más limpio de lo que lo encontraste». Corregir un bug debe considerarse un caso de refactorización; por lo tanto, debemos implementar sus técnicas. Aquí hay algunas específicas que deberían formar parte de tu caja de herramientas, aunque hay otras a considerar.

Deberíamos comenzar con una buena gestión del sistema de control de versiones, como Git. Al corregir bugs, debemos enfocarnos únicamente en el bug que pretendemos solucionar, evitando la tentación de corregir o limpiar otras partes del código. Esto último debería hacerse en un Pull Request (PR) separado.

Antes de abordar el bug, se debe maximizar la cobertura de pruebas del componente afectado. A veces, el componente es tan complejo que necesitamos desacoplar la parte del código que vamos a intervenir en nuevas funciones para facilitar su cobertura de pruebas y evitar introducir riesgos en otras partes del código. Si es posible, envía un PR solo con esta pequeña refactorización.

Luego, comienza con la cobertura de pruebas. Utiliza la técnica “Golden Master” de TDD (Test-Driven Development).Esto implica imprimir las entradas y salidas de la parte del código a tocar en la consola o logs. Luego, escribe las pruebas con esas entradas y salidas y observa la cobertura para identificar y cubrir casos no cubiertos, conocido en TDD como «Hit & Run”. En este punto, se puede enviar otro PR, ya que solo se ha aumentado la cobertura sin cambios en el código de negocio.

Con el comportamiento actual cubierto, usa TDD para corregir el bug. Debes crear una nueva prueba unitaria que reproduzca la situación exacta que causa el bug y comenzar la intervención para solucionarlo. La prueba debería fallar cuando se complete la corrección y luego reescribirse para que pase. Esto asegura que el bug se haya solucionado y documentado, minimizando la posibilidad de efectos secundarios o resultados no deseados.

¿Y ya está todo listo? No, todavía no. A continuación, pasa el código modificado por un analizador estático como SonarQube para verificar si se han introducido nuevos bugs, vulnerabilidades de seguridad o code smells (la hediondez del código) y solucionarlos antes de enviar el PR. Algunos desarrolladores pueden pensar que los code smells son meramente cuestiones estéticas, pero el código debe verse como un elemento de comunicación. Un code smell puede llevar a fallos o causar que otro desarrollador tome malas decisiones, como me sucedió en un equipo con el peor o más difícil bug que me he encontrado.

Finalmente, una revisión por pares de los cambios debería ayudarnos a determinar si el PR enviado está limitado solo a resolver el bug, si la intervención parece solucionar lo que propone y si no introduce nuevas situaciones a controlar. Es recomendable enfatizar y cuestionar el código eliminado.

El papel del QA al recibir la solución

En este esquema de alta ingeniería de software, QA cumple el rol de SDET (Software Development Engineer in Tests / Ingeniero de Desarrollo de Software Especializado en Pruebas); consulta este artículo: SDET vs QA: el debate más reciente en el Testing. Después de determinar y comunicar al desarrollador los pasos para reproducir el bug, el comportamiento esperado y el observado, el SDET debe diseñar pruebas unitarias para proteger el componente de comportamientos futuros inesperados. He usado «comportamientos inesperados» para aclarar que el proceso de ingeniería nunca puede garantizar la ausencia de bugs.

Una vez que el PR haya pasado la revisión por pares (en la sección anterior), el SDET puede intervenir en las pruebas realizadas por el desarrollador para estandarizarlas, mejorar la comunicación o incluso ampliarlas.

El bug se solucionó usando mejores prácticas de ingeniería. ¿Y ahora qué?

Después de esto, se pueden ejecutar pruebas manuales solo para verificar que el bug se haya solucionado efectivamente. No es necesario ejecutar pruebas exhaustivas o una regresión completa manual en partes del software que no se han tocado.

Pensar como ingenieros de software en lugar de programadores en la corrección de bugs nos permite fortalecer la estructura y calidad del código a largo plazo. Al aplicar mejores prácticas de desarrollo como la refactorización, TDD y revisiones por pares, no solo solucionamos problemas inmediatos, sino que también mejoramos la mantenibilidad y escalabilidad del software. Este enfoque nos brinda mayor confianza en nuestras soluciones, permitiéndonos avanzar más rápidamente y con mayor eficiencia en desarrollos futuros, ya que la calidad es el resultado de un compromiso continuo con la excelencia en cada paso del proceso de desarrollo.

¿Qué hago si mi equipo o líder técnico no quiere aplicar estas mejores prácticas de ingeniería?

Si los líderes o gerentes exigen implícitamente código de baja calidad y sin pruebas, deben estar preparados para lidiar con la deuda técnica y el software difícil de mantener. Un gran líder sabe cómo encontrar el equilibrio adecuado, como asignar tiempo para mejorar la calidad del código y las herramientas que usas. Al igual que cualquier deuda, la deuda técnica solo es problemática si no tiene un plan de pago.

Puede parecer agresivo decir «No estás haciendo ingeniería de software»; en su lugar, sugiere pequeños cambios incrementales para mejorar el resultado, como los siguientes:

• Establecer un proceso interno de revisión de PR para asegurar una revisión minuciosa del código y control de calidad.
• Implementar un plan de mentoría para cada módulo como parte del proceso interno de revisión de PR. El programa de mentoría puede ayudar a formalizar y compartir conocimiento antes de que los desarrolladores lo documenten en pruebas unitarias.
• Aumentar la cobertura de pruebas unitarias de los módulos problemáticos con mayor riesgo o cambios más frecuentes.
• Crear un plan para aumentar la cobertura con un objetivo de al menos 75% para fin de año.

Como QA o SDET, puedes ayudar a elevar las prácticas de ingeniería de software de tu equipo. Aboga por pequeños cambios incrementales para mejorar la calidad del código y la mantenibilidad.

Otros recursos

• 🎥 Video: Introducción en español refactorización / refactoring con TDD – 13 minutos por Codely TV.
• 🎥 Video: TDD Introduction (English) – 13 minutes.
• Foto: Campaign Creators.