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.

Le jour où le word s’arrêtera de tourner

Ras le bol des documents. 

On se surcharge de travail pour simplement fournir une preuve en cas de contrôle. Les plans projets, les doc de specs détaillées, les plans de gestion de conf, .... Quel développeur a déjà lu ces types de documents, non pas parce qu’il le devait, mais qu’il en avait besoin, pensait y trouver l’information.

L’information est nécessaire.
La capitalisation de l’information est nécessaire et indispensable, bien sûr. Je ne remets cela en cause d’aucune manière. C’est juste l’outil qui me hérisse le poil. Word c’est pour écrire des bouquins, pas des logiciels. Seul derrière son écran, pas en collaboration avec les collègues.

Ne pas confondre la réflexion et la persistance de la réflexion.

Un document a un propriétaire : l’auteur. Si le lecteur y trouve des incohérences, des erreurs ou seulement veut l’amender de sa propre expérience, il ne le fera pas, sauf contraint bien sûr.

On me rétorque à chaque fois qu’il faut documenter pour les générations futures. D’abord, il n’y a cas ne pas changer d’équipe à chaque fois qu’on fait une nouvelle version du produit, ça c’est dit ! Penser produit pas projet. Et puis, quand je reprends une application développée par d’autres, je préfère de loin avoir des tests unitaires me garantissant que je ne vais rien casser qu’une documentation dont je ne sais même pas si elle est à jour.

Moi je préfère le wiki !

Avec des pages courtes, un sujet par page.

Une organisation par liens, comme le net. Pas d’organisation au format document (chapitre, sous chapitre…), préférer des pages organisant les liens par séquence d’exécution ou de lecture, d’apprentissage … Utiliser les balises pour simplifier la recherche et l’organisation.

Autoriser et favoriser toute l’équipe à participer, modifier, commenter, amender.

Tout comme le code, refactoriser vos pages de temps en temps.  Si vous avez peur de supprimer une page, baliser la « obsolète » quelque temps.

Et pour ce qui est des « générations futures », le wiki a tout ce qu’il faut, export, sauvegarde, impression…

Amis agilistes, à vos wiki!

Lean Primer

Lean Primer de Craig Larman et Bas Vodde.
Traduction de Fabrice Aimetti et moi même.
Disponible ici ou sur le wiki de Fabrice.

AgileTour Toulouse 2011 : Inscriptions ouvertes

Ça y est, c'est parti.

L'inscription en ligne pour l'Agile Tour Toulouse 2011 est ouverte.

Cette année c'est 20€ pour les frais de repas (entre autre).

Paiement par carte bancaire.



Valtech est sponsor Gold sur cette édition locale.

J'y présenterai avec mon collègue Lionel Molas, un retour d'expérience sur "Agile à l'échelle".
Comment démarrer un projet en Agile, avec 70 personnes au début, 9 équipes, 3 sites, en 1 semaine et faut que ça tienne 2 ans quand même.