Blog de Bruno Orsier

Un article de Bruno Orsier    Commentaires fermés

J’aime bien lire des billets qui contiennent des informations factuelles sur de vrais projets, car cela permet de se situer par rapport à d’autres équipes et entreprises. Récemment j’ai vu notamment le billet Démarches de tests fonctionnels, de Christian Blavier, qui citait des chiffres intéressants (dans les commentaires du billet) :

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d’une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d’une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d’exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

Dans ces mêmes commentaires, Louis Pellerin ajoutait :

De mon expérience avec GreenPepper pour le produit Talia que nous développons (un produit sans réelle interface utilisateur), nous avions une proportion d’environ 80 spécifications exécutables (GreenPepper) pour plus de 200 tests unitaires et intégrés (mstest).

Il y a aussi le billet Pendant ce temps-là, à Boulogne., d’Emmanuel Gaillot, qui donne les chiffres suivants :

L’équipe compte actuellement 6 programmeurs (dont le responsable produit), 2 graphistes, 3 modérateurs et une poignée de stake-holders. Tout ce monde travaille dans un ancien atelier réhabilité à Boulogne, dans une même pièce. L’application web est développée en TDD (à l’exception des vues). Elle est actuellement couverte par 951 assertions, réparties sur 563 tests automatisés qui s’exécutent en 35 secondes environ.

En 4 mois de boulot, nous avons consommé 150 pages de flipchart, 15 marqueurs, 100 fiches cartonnées, 2000 post-its de couleurs et tailles variées, 10 stylos feutre, 5 stylos bic, 2 bloc-notes, 50 feuilles A4, un playmobil et 300 viennoiseries.

Si vous connaissez d’autres billets ou articles du même style je suis preneur.

En attendant voici quelques informations du même type sur l’un de nos projets : 38 sprints de développement (durée 3 semaines), une équipe de développement de (en moyenne) 4 développeurs et 1 chimiste testeur/représentant des utilisateurs (plus 1 ScrumMaster, et 1 Product Owner).

L’équipe a réalisé un total de 837 tests :

• 469 tests unitaires 

• 235 tests d’intégration

• 132 tests fonctionnels (81 manuels et 51 automatiques)

ce qui représente 84% de tests (unitaires + intégration) et 16% de tests fonctionnels, mais encore 90% de tests automatiques. Les tests fonctionnels manuels coûtent seulement 2-3 heures de validation à l’équipe, qui peut donc les jouer plusieurs fois par sprint si besoin.

Tous ces tests sont le résultat d’un effort permanent de toute l’équipe : TDD, automatisation des tests fonctionnels, « refactoring » permanent des tests fonctionnels.

Les tests unitaires et d’intégration représentent environ 3000 assertions. Ils sont exécutés avec DUnit.

Voici un graphique montrant l’évolution de la répartition des tests au fil du temps, sur les sprints les plus récents :

Voici la légende et la répartition finale (où j’ai regroupé tests fonctionnels automatiques et manuels en une seule catégorie).

Cette répartition paraît assez satisfaisante : on a bien une pyramide de tests, il y plus de tests unitaires que de tests d’intégration, et plus de tests d’intégration que de tests fonctionnels. D’autre part le nombre de tests fonctionnels manuels est resté sous contrôle, et c’était l’un des objectifs de l’équipe de pouvoir exécuter tous leurs tests manuels en moins d’une demi-journée ; le graphique montre d’ailleurs qu’en cours de route, certains tests manuels ont été remplacés par des tests automatiques, afin de ne pas se laisser déborder par les tests manuels.

C’est un projet qui compte environ 180.000 lignes de code Delphi. C’est un projet de taille moyenne pour nous, nous avons des projets beaucoup plus petits, et de plus rares projets 5 ou 6 fois plus gros.

Sur ce projet, comme sur un projet précédent d’ailleurs, nous avions décidé de maîtriser la complexité cyclomatique (nous étions motivés par la constatation sur d’anciens projets que des méthodes de complexité 50 voire 70 étaient de véritables nids à bugs critiques). Le graphique ci-dessous montre sur les sprints les plus récents l’évolution du nombre total de méthodes (en bleu), et l’évolution du nombre total de méthodes dont la complexité cyclomatique est supérieure à 7 (notre limite). Sur ce projet, nous avons donc programmé plus de 6200 méthodes de complexité inférieure à 7. Toutefois nous tolérons l’existence de quelques dizaines de méthodes complexes car le bénéfice de baisser leur complexité ne nous semble pas assez important. Mais ces méthodes complexes ne représentent que 0.6% du nombre de total de méthodes !

La définition de la limite acceptable (7 dans notre cas) peut donner lieu à bien des débats, et vous trouverez fréquemment des recommandations comme 15 ou 25. Mais à mon avis, même une limite de 7 vous donne bien des opportunités de coder des bugs, car cela vous laisse libre de coder suffisamment de if, while, for et conditions booléennes tous ensemble. Donc pour moi il est important de s’imposer une limite assez basse pour vraiment tirer parti de la réduction de la complexité.

Ces données illustrent deux axes sur lesquels nous nous sommes bien améliorés ces dernières années : maîtrise des tests, maîtrise de la complexité du code. Et qu’en est-il de la satisfaction des clients sur ce projet ? Eh bien c’est assez embarrassant, je ne sais pas encore quelle est la réponse ! En effet, en nous améliorant, nous avons essentiellement déplacé le goulet d’étranglement dans d’autres secteurs de l’entreprise qui actuellement peinent à absorber notre production, et à livrer leur part du travail (pourtant ils ont vu passer plus de 30 livraisons qui fonctionnaient, ils n’auraient pas dû être surpris, non ?).

Après tout, rien de très surprenant, c’est en gros ce que prédit la théorie des contraintes.  Mais cela indique que dans de futurs projets, tout en continuant à nous améliorer sur d’autres axes (comme travailler avec des exemples et pratiquer le BDD), il va falloir travailler à introduire de l’agilité dans tous les secteurs qui contribuent à la livraison d’un produit chez des clients ! Nous atteignons peut-être les limites de ce que nous pouvons faire avec des améliorations locales.

Merci à mes collègues Sandrine et Jean pour leur aide dans la collecte des données.