Costo y valor de un test automatizado según Brian Marick

Luego de haber terminado la VelocityConf en San José, me vuelvo a sentar en la compu. Aprovecho para brevemente compartir algo que leí hace poco, y que a partir de eso se generó un lindo intercambio de ideas dentro de Abstracta. A ver qué te parece esto que pone Brian Marick en este paper: When should a test be automated.

Si te parece muy largo para leerlo, te pego acá el resumen que aparece al final del paper. Me resultan súper interesantes los dos puntos, más que nada porque nunca lo había pensado desde esa perspectiva:

This paper sketches a systematic approach to deciding whether a test should be automated. It contains two insights that took me a long time to grasp – and that I still find somewhat slippery – but which seem to be broadly true:

1. The cost of automating a test is best measured by the number of manual tests it prevents you from running and the bugs it will therefore cause you to miss.

2. A test is designed for a particular purpose: to see if some aspects of one or more features work. When an automated test that’s rerun finds bugs, you should expect it to find ones that seem to have nothing to do with the test’s original purpose. Much of the value of an automated test lies in how well it can do that.

El primer punto habla sobre la forma de medir el costo de un test, indicando que está asociado a los bugs que pueden aparecer dado que ya no vamos a ejecutar manualmente algunos tests. O sea, si automatizás un test, ya no lo vas a ejecutar manualmente. Si eso es así, podés llegar a no encontrar bugs en esas funcionalidades y que se te escapen a producción. Ahí está el costo del test automatizado. A lo que llegamos en nuestra discusión en la interna, es que todo esto no es “automatizo un test y ya no toco eso en ninguna prueba manual”, sino que la estrategia de pruebas debería cubrir ambas cosas para los tests más críticos, pudiendo así reducir este costo que apunta.

El segundo entiendo que se refiere a que un test termina encontrando más bugs en cosas que no tienen que ver con el propósito principal del test.

Leave a Reply

Your email address will not be published. Required fields are marked *