Je n'ai pas de documents de recherche ou de statistiques à vous fournir, mais je vais vous raconter mon expérience de travail dans une équipe / organisation qui, historiquement, avait une couverture de tests unitaires faible à moyenne et aucun test de bout en bout, et progressivement déplacer la barre là où nous en sommes maintenant, avec plus d'une approche ATDD (mais, ironiquement, pas traditionnelle TDD).
Plus précisément, c'est ainsi que les échéanciers du projet se déroulaient (et se déroulent toujours sur d'autres équipes / produits de la même organisation):
- Jusqu'à 4 semaines d'analyse et de mise en œuvre
- 2 semaines de tests de régression, correction de bogues, stabilisation et préparation de versions
- 1-2 semaines de réparation des défauts connus
- 2-3 semaines de nettoyage de code et problèmes / support de post-production (défauts inconnus / pannes imprévues)
Cela semble ridicule, mais c'est en fait très courant, il est souvent masqué dans de nombreuses organisations par une assurance qualité manquante ou inefficace. Nous avons de bons testeurs et une culture de tests intensifs, donc ces problèmes sont détectés tôt et résolus à l'avance (la plupart du temps), plutôt que d'être autorisés à jouer lentement au cours de plusieurs mois / années. Les coûts de maintenance de 55 à 65% sont inférieurs à la norme communément acceptée de 80% du temps consacré au débogage - ce qui semble raisonnable, car nous avons eu quelques tests unitaires et des équipes interfonctionnelles (y compris l'AQ).
Lors de la première version de notre dernier produit par notre équipe, nous avions commencé à moderniser les tests d'acceptation, mais ils n'étaient pas tout à fait à la hauteur et nous devions encore compter sur de nombreux tests manuels. La publication a été un peu moins douloureuse que d'autres, l'OMI en partie à cause de nos tests d'acceptation au hasard et aussi en partie à cause de notre couverture de tests unitaires très élevée par rapport à d'autres projets. Pourtant, nous avons passé près de 2 semaines sur la régression / stabilisation et 2 semaines sur les problèmes de post-production.
En revanche, chaque version depuis cette version initiale a eu des critères d'acceptation et des tests d'acceptation anticipés, et nos itérations actuelles ressemblent à ceci:
- 8 jours d'analyse et de mise en œuvre
- 2 jours de stabilisation
- 0-2 jours combinés de support et de nettoyage post-production
En d'autres termes, nous sommes passés de 55 à 65% de frais de maintenance à 20 à 30% de frais de maintenance. Même équipe, même produit, la principale différence étant l'amélioration progressive et la rationalisation de nos tests d'acceptation.
Le coût de leur maintenance est, par sprint, de 3 à 5 jours pour un analyste QA et de 1 à 2 jours pour un développeur. Notre équipe compte 4 développeurs et 2 analystes QA, donc (sans compter l'UX, la gestion de projet, etc.), c'est un maximum de 7 jours-homme sur 60, que j'arrondirai à une surcharge de mise en œuvre de 15% juste pour être sur le côté sûr.
Nous passons 15% de chaque période de mise au point à développer des tests d'acceptation automatisés, et dans le processus, nous sommes en mesure de réduire 70% de chaque version en effectuant des tests de régression et en corrigeant les bogues de pré-production et de post-production.
Vous avez peut-être remarqué que la deuxième chronologie est beaucoup plus précise et aussi beaucoup plus courte que la première. C'est quelque chose qui a été rendu possible par les critères d'acceptation et les tests d'acceptation initiaux, car cela simplifie considérablement la "définition du fait" et nous permet d'être beaucoup plus confiants dans la stabilité d'une version. Aucune autre équipe n'a (jusqu'à présent) réussi avec un calendrier de publication bihebdomadaire, sauf peut-être lors de versions de maintenance assez triviales (correction de bugs uniquement, etc.).
Un autre effet secondaire intéressant est que nous avons pu adapter notre calendrier de sortie aux besoins de l'entreprise. Une fois, nous avons dû l'allonger à environ 3 semaines pour coïncider avec une autre version, et nous avons pu le faire tout en offrant plus de fonctionnalités, sans passer de temps supplémentaire à tester ou à stabiliser. Une autre fois, nous avons dû la raccourcir à environ 1½ semaine, en raison de vacances et de conflits de ressources; nous avons dû prendre moins de travail de développement, mais, comme prévu, nous avons pu consacrer en conséquence moins de temps aux tests et à la stabilisation sans introduire de nouveaux défauts.
Ainsi, d'après mon expérience, les tests d'acceptation, en particulier lorsqu'ils sont effectués très tôt dans un projet ou un sprint, et lorsqu'ils sont bien entretenus avec des critères d'acceptation écrits par le propriétaire du produit, sont l'un des meilleurs investissements que vous puissiez faire. Contrairement au TDD traditionnel, qui, à juste titre, est souligné par d'autres, se concentre davantage sur la création de code testable que sur un code sans défaut - ATDD aide vraiment à détecter les défauts beaucoup plus rapidement; c'est l'équivalent organisationnel d'avoir une armée de testeurs faisant un test de régression complet tous les jours, mais beaucoup moins cher.
ATDD vous aidera-t-il dans des projets à plus long terme réalisés en style RUP ou (ugh) Waterfall, des projets d'une durée de 3 mois ou plus? Je pense que le jury est toujours sur celui-là. D'après mon expérience, les risques les plus importants et les plus laids dans les projets de longue durée sont des délais irréalistes et des exigences changeantes. Des délais irréalistes obligeront les utilisateurs à prendre des raccourcis, y compris des tests de raccourcis, et des modifications importantes des exigences invalideront probablement un grand nombre de tests, les obligeant à être réécrits et à gonfler potentiellement les frais généraux d'implémentation.
Je suis à peu près sûr qu'ATDD a un gain fantastique pour les modèles Agile ou pour les équipes qui ne sont pas officiellement Agiles mais ont des calendriers de sortie très fréquents. Je ne l'ai jamais essayé sur un projet à long terme, principalement parce que je n'ai jamais été dans ou même entendu parler d'une organisation disposée à l'essayer sur ce type de projet, alors insérez l'avertissement standard ici. YMMV et tout ça.
PS Dans notre cas, aucun effort supplémentaire n'est requis de la part du "client", mais nous avons un Product Owner dédié à temps plein qui rédige en fait les critères d'acceptation. Si vous êtes dans le domaine du "consultingware", je pense qu'il pourrait être beaucoup plus difficile d'amener les utilisateurs finaux à écrire des critères d'acceptation utiles. Un Product Owner / Product Manager semble être un élément assez essentiel pour faire de l'ATDD et bien que je ne puisse à nouveau parler que de ma propre expérience, je n'ai jamais entendu parler d'ATDD pratiqué avec succès sans quelqu'un pour remplir ce rôle.
