Calidad sin cuellos de botella

¿Alguna vez tuviste que borrar pruebas de aceptación de punta a punta porque tu Integración Continua se volvió inaceptablemente lenta? A todos nos ha pasado.

Las pruebas de aceptación de punta a punta son muy significativas porque prueban como se espera que el sistema se comporte desde la perspectiva del usuario final y en un entorno muy similar al real. Sin embargo, abusar de este tipo de pruebas para probar todo en un sistema puede hacer que el pipeline se convierta en un cuello de botella, que el mantenimiento de las pruebas se transforme en una carga excesiva para los desarrolladores, y que el feedback se demore horas (¡o días!).

Entonces, ¿cómo hacemos para mantener una alta calidad sin sacrificar la eficiencia? Acá van algunas estrategias:

• Pensar qué errores no podemos permitirnos e identificar cuáles son los flujos críticos del sistema, los que se alinean con los objetivos del negocio, para concentrar allí las pruebas más significativas (es decir, las pruebas de aceptación de punta a punta). El resto de los caminos pueden probarse con otros tipos de pruebas menos costosas (de API, unitarias, de aceptación rápidas).

• Encontrar el equilibrio adecuado entre los distintos tipos de pruebas priorizando la confiabilidad y la velocidad de ejecución (que se traduce en un feedback temprano) pero sin perder de vista la significatividad de las pruebas. Por ejemplo, incrementar la cobertura agregando pruebas de getters y setters, por más rápidas que sean, no aporta mucho valor.

• Reemplazar las dependencias externas por versiones falsas en memoria (mocks o stubs) y agregar pruebas de contrato que validen que las interfaces con esas dependencias se mantienen como se espera.

• Reducir el alcance del sistema a probar ejecutando algunas pruebas de aceptación en test assemblies más acotados. Conocé más cómo trabajamos acá.

¿Te pasó alguna vez? ¿Cómo manejaste el exceso de pruebas de punta a punta en tu

proyecto? ¡Contanos tu experiencia!

Natalia Lehmann