Intérêt de l'automatisation des tests

Suite à la lecture du billet sur l’intégration continu, un internaute voulait savoir comment vendre l’intérêt de l’automatisation de tests. Voici la réponse que je lui ai faite :

D'abord, on va parler argent, puisque c'est pour vendre!

Il faut voir pourquoi l'automatisation ne doit pas être vu comme un surcoût.

Dans un cycle de développement classique (V, cascade, RUP), il n'y a qu'une phase de livraison en fin de développement. De une à 4 par an, souvent.

Dans un cycle itératif (Agile, Lean), il y a un livraison possible au minimum à chaque fin d'itération : de 12 à 24 fois par an.

Le coût de l'automatisation est donc divisé de 6 à 24 fois.

Et de plus de 220 fois (nombre de jours ouvrés) pour ce qui est des tests unitaires passés au minimum 1 fois par jour.

Pas négligeable quand même.

Ensuite, les approches Test Driven (TDD, TDR, A-TDD) sont réputées pour diminuer le taux d'erreur et d'insatisfaction.

Taux d'erreur = bugs

Taux d'insatisfaction = incohérence aux réels besoins métiers, pas forcément à la spec

Leur automatisation garanti donc ce contrôle en continu. Et vous avez raison, aide au contrôle des effets de bords et à la fiabilisation.

Ces tests apportent aussi une "documentation" efficace du produit pour la maintenance de celui-ci:

Un nouveau développeur ou une nouvelle équipe sur un produit aura plus d'assurance de compréhension, de maintenabilité et de pérennité qu'en lisant la spec détaillée. Là aussi, gain économique si les charges sont favorisées sur les tests unitaires plutôt que sur de la doc inutile.

Côté fonctionnel, c'est un peu différent:

Pour moi, les tests fonctionnels sont là pour valider le produit au sens métier.

Si vous utilisez les pratiques TDR et/ou A-TDD, c'est extrêmement efficace et souvent peu coûteux de les automatiser.

Pour faire court, en A-TDD la spécification fonctionnelle est remplacée par des scénarios de tests. Leur automatisation est supportée par de nombreux outils (QTP, robotframework, ...).

Sinon, il est tout à fait possible d'automatiser des scénarios de tests "standards", mais leur maintenance peut s’avérer plus coûteuse, s'ils n'ont pas été pensés pour : Factorisation des cas de tests, double écriture des tests, par le métier dans un outil, puis par les développeurs dans l'automate de test.

Je conseille fortement dans ce cas l'utilisation d'outils dit "keyword driven", tels que robotframework, qui permettent d'utiliser le même outil pour les deux mondes.

Leur automatisation favorise donc effectivement la non régression et peuvent être utilisés sur des tests de performances et de montée en charge.