Una parte importante del desarrollo de software, y que puede ser extendido a otro tipo de disciplinas, es lo que se suele denominar la “fase de pruebas”. El hecho de que se le llame “fase” deriva del método tradicional de desarrollo, copiado del sistema de fabricación “por proyecto”. Un sistema en el que, por ejemplo y simplificando mucho, para fabricar un barco, primero se hacen los planos, luego se construye y por último se prueba.
Este modelo simplificado de diseño-desarrollo-prueba ha mostrado en muchas ocasiones no ser el mejor para desarrollar software. En cierta medida, tampoco es el mejor en otras áreas. Por ejemplo, en el citado ejemplo de la fabricación de un barco, muchos subsistemas son probados a medida que se va construyendo el mismo. Es precisamente lo que propugna la metodología Agile: prueba lo antes posible. Siempre que se haga un cambio significativo en el desarrollo, debe probarse la mayor cantidad posible del producto final.
Además de la evidente ventaja de detectar los problemas de forma temprana, el enfoque de “prueba contínua” requieren un diseño de la solución y una infraestructura que lo permita, que lo automatice lo más posible. En caso contrario, realizar pruebas se convierte en la parte más tediosa del trabajo.
Para aquellos que usan Scrum (o similar, basado en iteraciones) un consejo: no convirtáis los sprint en mini-waterfall. Dicho de otro modo, no hay que tener una “fase de pruebas” al final de la iteración, hay que procurar integrar las pruebas en el flujo de trabajo diario.
