Accueil > Divers, MMIT > [MMIT] De l’intérêt des tests et de leur automatisation

[MMIT] De l’intérêt des tests et de leur automatisation


Cela fait cinq semaines que je travaille (entre autres) sur de l’automatisation de tests.
Il y a beaucoup de choses que j’ai pu faire, d’autres que je souhaite faire et j’ai envie d’en parler un peu (j’y reviendrais sur plusieurs billets qui seront liés).

Je parle ici bien de tests automatisés et non de tests automatiques.
Les tests automatisés sont des tests écris à la main (du moins en partie) et pouvant s’appuyer sur un cahier de tests et dont l’exécution est automatique (clic droit, « Exécuter »).
Les tests automatiques, eux, sont des tests générés de façon automatique (par Visual Studio, par exemple).
La différence que je fais est dans le but : les premiers sont plutôt fonctionnels (vérifier qu’un scénario donne le résultat attendu) tandis que les seconds sont techniques (vérifier que telle méthode fait bien ce qui est prévu).
Les tests automatisés sont donc mécaniquement plus complexes.

Ainsi, dans le présent billet, je vais parler des tests automatisés en général, ce qui va servir d’introduction et de cadre pour les billets suivants.

 

Pourquoi mettre en place des tests automatisés ?

 
Lors du développement d’un logiciel (privé ^^), il y a forcément un moment où la recette arrive.
En général, dans une entreprise, il y a une équipe de recetteurs qui s’y colle (avec plus ou moins de bonheur et d’entrain…).

Prenons un exemple d’une application « legacy » (une application que l’entreprise traîne depuis un moment et qui est migré de Framework en Framework, avec un nombre de développeurs important ayant travaillé dessus).
A chaque correction/évolution, il faut obligatoirement effectuer une recette et des tests de non régression.
Ce qui veut dire que les recetteurs vont passer un temps fou à tout tester.
Parfois, ils devront le faire dans des délais très courts, parfois sans réellement connaître l’application (ie: en suivant un « test plan », avec HP Quality Center; note : ce n’est pas de la pub, c’est le seul que je connaisse, avec un avis partagé) et parfois avec des tests très peu poussés.
Et pour chaque recette, il y a très (trop) souvent des retours : bugs qui doivent être corrigés ou évolutions suite à des spécifications aussi venteuses que le Mistral.

Après corrections / développements, il faut donc refaire un recette. La boucle est bouclée…
Le nombre de cycles recette-corrections peut être assez important en fonction de la complexité de l’application.
Durant cette phase, il est TRÈS facile de se prendre un dépassement de planning considérable (à moins de sacrifier la qualité du livrable au profit des délais).

On en vient donc aux tests automatisés.
Leur gros intérêt est de pouvoir tourner rapidement, dans le cadre d’une intégration continue, par exemple.
Ainsi, avoir des tests automatisés permet de les faire tourner rapidement (c’est déjà un premier point important), sans avoir besoin d’intervention humaine (donc le midi, la nuit..) et de fournir un rapport de ce qui va. Ou pas.
Ils permettent donc de réaliser une première recette qui permet de voir le plus rapidement possible ce qui ne fonctionne pas ou plus.

Comme l’application va être testée de façon plus poussée en phase de développements (ou recette interne, recette études ou quelque soit le nom de cette phase), cela veut dire que l’on va mettre des choses en lumière avant de transmettre à une autre équipe. Et donc, que l’on pourra réaliser des corrections avant la recette, ce qui implique moins de bugs en recette et donc moins d’allers-retours (qui sont très chronophages).

 

Avantages et inconvénients

 
Une solution est donc de réaliser, en parallèle des développements, un projet de tests.

La couverture du code est une approche. Quand on parle de couverture de code, il est facile de vouloir tendre vers les 100%.
A mon sens, elle n’est pas forcément la plus pertinente car elle est extrêmement chronophage (et on a des délais à tenir, quand même ! ^^) et il est également possible d’avoir des redondances dans les tests (dans une architecture n-tiers, on pourra vouloir tester toutes les couches successives, donc dans les couches les plus hautes, tester in fine des méthodes déjà testées dans les couches basses).

Je préfère une approche plus fonctionnelle : créer des cas de tests qui correspondent à la vie de l’application.
Là aussi, il peut y avoir un nombre de tests très importants, mais au moins, ces tests répondent aux besoins / aux exigences.

Pour commencer, il faut à minima les « happy flow » (dixit un excellent chef de projet avec qui j’ai pris plaisir à travailler !), c’est à dire les cas qui doivent passer, les cas les plus simples.
Ensuite, il faut continuer avec les tests des erreurs attendues et complexifier les tests de façon progressive
Il y aura forcément des parties de code réutilisable, donc pas besoin de réinventer la roue à chaque fois : on prend des bouts de code déjà prêt pour avancer plus vite sur les parties connues.
Et enfin, des tests plus poussés ou libre, en fonction de ce que l’on peut penser (une concertation avec les MOAs et/ou le métier peut être très utile).

Avec cela, il y a toute une batterie de tests (qui vont recouper les tests de recette, parfois aller plus loin) qui sera exécutée.
Mais dans tous les cas, ils vont pouvoir tourner de façon régulière et rapidement.

Un autre point, que je considère comme étant important.
Puisqu’il y a des tests automatisés couvrant les cas fonctionnels de base (ou plus poussés), cela permet que l’équipe de recette passe rapidement ces tests (histoire de vérifier que c’est vraiment bon) pour réaliser des tests libres.
Car au final, une bande de recetteurs qui stressent un peu l’application, c’est le meilleur des tests.
Suivant leur inspiration du moment, ils peuvent déterrer des trucs vraiment importants (que l’on ne pourrait jamais trouver avant les utilisateurs finaux en production, du fait que les recetteurs suivent le même plan de tests que les développeurs…).
Les tests libres sont ce qu’il y a de mieux après les tests automatisés.

Cependant, il ne faut pas oublier que les tests automatisés sont du développements.
Ils ont donc un coût initial (parfois important) et un coût de maintenance (car des tests non maintenus peuvent être trompeurs et faire perdre du temps).
Et comme c’est du développement, il y a également un risque de bugs (entraînant des faux-positifs ou masquants des bugs).
Il faut donc pouvoir tracer les tests et les résultats pour pouvoir les comparer de façon successives (s’il y a eu une modification dans un tests qui entraîne un résultat totalement déconnant, il est utile d’avoir sous la main un résultat correct précédent).

 

Quelques chiffres

 
Pour donner tout de suite des chiffres.
Actuellement, je suis à 20 j/h de développements autour des tests automatisés (sur une application existante).

J’ai créés 33 cas de tests, ils comprennent :

  • Création d’un jeu de données de tests
  • Lancement du batch (puisque c’est la cible du test)
  • Récupération des données générées par le batch
  • Validation et contrôle de cohérence des données
  • Suppression de toutes les données du cas de test (pour revenir à l’état antérieur de la base)

Les 33 cas de tests tournent en moins de 5 minutes.

Auparavant, il fallait 3 personnes durant 3 semaines, donc 45j/h, pour réaliser moins de cas de tests.

L’étape suivante est d’élargir progressivement les tests à d’autres pans de l’application (et j’espère, pousser vers de l’intégration continue, ou même du Test Driven Development).

 

Conclusion

 
Si les tests ont un coût initial potentiellement important (comme dans mon cas lorsque les tests sont décorrelés de la solution [*.sln] cible ou ou parce qu’ils sont réalisés à posteriori), il faut bien comprendre que l’avantage est sur le long terme.

En effet, si les développements initiaux de l’applicatif pourront allonger un peu les délais, ceux-ci vont être moindre lors de la recette (du fait d’une application plus testée donc plus stable) et auront un impact non négligeable sur la maintenance (moins de bugs, moins de maintenance, rapidité à voir ce qui pose problème, etc.).
En général, moins de bugs permet également d’avoir une satisfaction client plus importante. Et ça, ça n’a pas de prix !

Donc, les tests, c’est le bien, mangez-en.
Et c’est le premier pas vers de l’intégration continue et/ou du TDD.
De plus, la suite Visual Studio donne bien assez d’outils pour les gérer.
Avec TFS derrière, il est possible d’aller vraiment très loin.
Ça serait vraiment trop bête de s’en priver !

Catégories :Divers, MMIT
  1. 16/12/2012 à 19:56

    Les tests ce n’est pas vraiment la partie la plus amusante à faire dans le cycle de vie d’une application. Cet article est bien intéressant et c’est plutôt avantageux de finir avec seulement 20j/h comparé à la mise à disposition de 3 personnes pour un total de 45j/h, surtout lorsque l’ont connaît l’engouement (ironie) des développeurs pour ces tests.
    Donc au final : gain de temps, plus de tests effectués et moins de perte de motivation dans les équipes de travail.🙂

    • 17/12/2012 à 10:18

      Je ne pensais pas non plus que ce serait très folichon, mais…
      En général, les tests n’ont pas d’existences en dehors de l’équipe qui les développe, cela peut être un bon moyen d’expérimenter, de se former, c’est là que l’on peut pousser un peu la technique (l’application que je dois tester est en .Net 2.0, le projet de tests en 4.0).

      Le chef de projets m’a entièrement fait confiance en me donnant carte blanche (ce qui fait plaisir et qui motive), j’ai pu faire des choix et expérimenter (donc me faire plaisir) pour au final explorer des pistes que nous n’avions pas envisagés (meilleure implication et meilleure couverture de tests).
      Donc, en bilan, c’est tout bénéfices !🙂

      En attendant, pour continuer sur des chiffres :
      Réalisation d’un test simple et/ou à l’image d’un autre : ~0.5 j/h
      Réalisation d’un test complexe (création de jeu de données, etc.) : ~2 j/h
      Après 1 mois, le projet compte 43 tests (+10) et 31 validateurs (+15; validateur : méthode de validation permettant de vérifier que les résultats obtenus sont ceux attendus).

  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :