intive Argentina Blog

La historia de Pepe y el unit testing

― Pepe, te fallaron los tests ―dice el TL desde su puesto.

Y entonces Pepe va, los revisa, no entiende el error y decide que, por falta de tiempo o de vaya usted a saber qué, es mejor continuar así y deployar a QA, mandando la funcionalidad como Dios la trajo al mundo: crudita y sin pasar por la cocina del test unitario. Todo se rompe por cualquier lado, da miedo siquiera mirar la aplicación. Acto seguido, tenemos un QA testeando sobre un grotesco y rojo error 500.

El objetivo del unit testing, es lograr una primera instancia en la que se revise el funcionamiento de un área del código y su comportamiento en relación a otras partes de este, para luego proceder a otras etapas del testing que comparten tanto los Devs como los QAs. Porque, si bien el QA es responsable de la calidad del producto en sí, el Dev es responsable de la calidad del código que crea y de su optimización.

Sin embargo, este testing mínimo del código, más que un requisito o mandatory field durante el ciclo del desarrollo, es una convención sobre la que decide empoderarse el equipo para trabajar sobre un código más confiable y sencillo de mantener. Este acuerdo puede no existir. A veces pasa.

¿Por qué el unit testing es una convención y no un hábito?

Pepe diría que “hay que cumplir con los tiempos de entrega”, otros podrían asegurar que no estaba dentro de los requerimientos. Lo cierto es que la vorágine de muchos proyectos (porque en el mundo real nadie puede explayarse a codear ni a testear como quisiera), promueve situaciones en las cuales las buenas prácticas quedan ahí: en algún rincón inalcanzable que tal vez, cuando se pueda, podríamos implementar.

Ahora, ¿le suma valor al producto y al equipo? Desde los zapatos del programador, el abanico de ventajas abarca las mismas que siempre se fomentan: ayudar a entender mejor el código y la lógica del negocio, reducir problemas futuros de integración y promover la refactorización y la optimización, entre otras. Pero específicamente, ¿cómo influye este proceso en la carga de QA? ¿Y en las entregas? ¿O en la organización del equipo?

Un embedded QA

Un programador que lleva a cabo un conjunto de pruebas, entre ellas las unitarias, asegura que el código haya pasado por un par de depuraciones importantes que garantizan cierta estabilidad. Esto significa que, aunque probablemente carezca de algunas validaciones, el código hará lo que debe hacer.

Es luego de este proceso que el código pasa a las manos del analista QA, en una suerte de testing que va a denominarse (y no en el estricto sentido técnico de la palabra), preintegración. Se le llama preintegración porque es acá cuando el acto de testear se lleva a cabo en el ambiente de desarrollo, o antes de que el código se comitee en un branch unificado.

El QA que sigue esta metodología, sería lo que hemos denominado desde nuestra Brigada de Calidad, un embedded QA. Se trata de un profesional con acceso al código, capaz de manejar Git con el objetivo de ir probando una unidad funcional, y de evitar la mayor cantidad de bugs y sorpresas posibles al último minuto, que por lo general, es el explosivo momento de una demo.

Ayudemos a Pepe

Desde intive-FDV, los líderes de calidad de nuestras brigadas han alabado este procedimiento porque permite encontrar issues críticos en una etapa joven del ciclo, de “limpiar y lustrar”, de proporcionar el primer feedback de la aplicación, de priorizar, de invertir tiempo para solucionar complejidades; es decir, de proveer al equipo de un diagnóstico casi precoz de cómo conducir las expectativas tanto para ellos mismos como para el cliente.

Es entonces la preintegración una suerte de familiar escondido del Test Driven Development (TDD) que, en igualdad, ruega por la calidad del software, pero desde una vista panorámica, práctica, ágil y de gestión en lugar de dedicarse solo al ojo técnico.

Si trabajas con Pepe, por favor dile que lea esto, tal vez no esté enterado de los múltiples beneficios de este paradigma, o quizá no sepa cómo implementarlos; o simplemente lo que necesite sea formar parte del equipo de intive-FDV.

Ilein González

Ilein González es licenciada en Comunicación Social, mención periodismo, graduada de la Universidad Católica Andrés Bello. Desde mayo del año 2018 se desempeña como Analista de Calidad en intive-FDV, en uno de los proyectos más desafiantes de la compañía. Ilein es además una entusiasta de la innovación y los procesos.

Deja un comentario