Tester pendant le sprint

L'importance des tests pendant le sprint

Tester pendant le sprint plutôt qu'à la fin du sprint ou après fait partie des valeurs exprimées dans le manifeste du test agile [Laing 2016] [Moustier 2019-1]. Cela signifie que le test agile est une activité plutôt qu'une phase ; par conséquent, si le tableau Kanban affiche une colonne pour les questions de test, cela va certainement générer plus de WIP. Finalement, l'organisation peut accepter une qualité médiocre ou même un aveuglement volontaire sur des problèmes prévisibles dans un état d'esprit "ça va aller", mais les coûts post-déploiement générés sont bien connus pour être plus importants selon l'approche First Pass Yield.

De plus, l'incrément de produit est potentiellement expédiable à la fin du sprint et toutes les histoires d'utilisateur livrées (US) doivent au moins être conformes à Definition of Done (DoD) [Schwaber 2020]. Cela implique que La DoD devrait inclure certaines ENF à tester ou une partie d'entre elles et qu'une autre partie liée à l'ensemble du produit devrait être abordée une fois que toutes les US sont intégrées.

En outre, l'état d'esprit DevOps oblige les développeurs à automatiser tout ce qu'ils peuvent afin d'éviter les coûts des retards [Reinertsen 2009] introduits par les opérations manuelles telles que les tests de régression.

Tous ces éléments liés aux activités de test doivent être réalisés dans un délai très court.

Impact sur la maturité des tests

Tester à la fin du sprint ou même après, c'est considérer les tests comme une phase. Cela place généralement l'état d'esprit de n'importe quel testeur à "J'ai ma propre rubrique" ou pire encore "Je me bats contre l'équipe" alors que considérer les tests comme une activité devrait faire évoluer n'importe quel testeur à "Je fais partie du conseil" [Laing 2016] et donc comme un membre de l'équipe, c'est-à-dire "L'équipe est responsable de la qualité du produit".

Cependant, supporter toutes les activités présentées ci-dessus pendant le sprint est un véritable défi que les pratiques agiles aident à relever.

L'approche à adopter est alignée sur le Shift Left Testing qui vise à prévenir bugs plutôt qu'à trouver des solutions. Définir des critères d'acceptation (AC) sur USavec des "spécifications par exemple" (SBE) et ATDD est un très bon début pour un Sprint. Cette approche indique à l'équipe que la conformité du DoD avec tous les AC's qui ont été acceptés rend le projet les US fait " fait ". Puisque les CA fournissent des tests à effectuer, les US la durée devient prévisible et les tests sont inclus dans la charge de travail. Étant donné que les développeurs savent ce qu'il faut tester, ils peuvent introduire le codage avec une approche "Test First" telle que TDD. Ensuite, dès qu'une partie du processus métier est disponible, les tests de bout en bout peuvent être effectués dès que possible. Ces pratiques agiles insèrent les tests aux premiers stades du SDLC et changent la donne en rendant l'ensemble de l'équipe responsable de la qualité du produit. 

Un autre aspect de ces pratiques agiles consiste à faire plus avec moins en faisant plusieurs choses en même temps, par exemple :

• 3 Amigos qui génère à la fois US et les cas de test  
• ATDD qui donne des spécifications exécutables [Ambler 2005], c'est-à-dire des AC, des SBE et des tests automatisés.
• TDD qui génère la conception, les tests unitaires et le code de production
• Laprogrammation en binôme ou la programmation en groupe, qui permettent à la fois le codage et la révision du code.
• Destests exploratoires qui permettent à la fois d'écrire et d'exécuter des tests.

Ces pratiques de test peuvent également être optimisées en termes de flux avec le modèle organisationnel "Task Force US" et un état d'esprit de type T-Shape.

De plus, si le travail à faire semble trop important pour le Sprint, il est toujours possible de faire une technique de Story Splitting [Lawrence 2012][Le Lan 2018] pour permettre l'expédition du code en production. S'il apparaît que le code expédiable ne correspond pas à un MMF et qu'il livre donc quelque chose qui ne serait pas assez bon pour un client, l'équipe peut toujours déployer le code en mode Dark Launch.

Si aucune de ces techniques n'est applicable ou si les attentes des clients en matière de qualité ne sont que partiellement satisfaites, l'incrément de produit diminue alors le budget d'erreurs qui doit être remboursé par des remaniements post-déploiement. Cependant, si les clients ont atteint un point de basculement [Gladwell 2001], ils peuvent abandonner le produit.

Pour éviter la fuite de la plupart des Clients, le concept de Shift Right DevOps peut être d'une certaine aide à condition que 

• Lesuivi de la solution est assuré si vous disposez d'observables automatisés pour l'utilisation des produits afin de surveiller à la fois le commerce et les affaires.
• un mécanisme très Andon est mis en place au sein de l'équipe pour récupérer rapidement les problèmes trouvés.
• et Canary Releasing est appliqué pour limiter le mécontentement de certains Utilisateurs et éviter des départs massifs

Le point de vue d'Agilitest sur les tests pendant le sprint

Les utilisateurs d'Agilitest sont encouragés à fusionner le développement et l'automatisation des tests et à participer aux ateliers "3 Amigos" / "Example Mapping". ATDD devrait également être utilisé pour que les scripts de test fassent partie du développement, en particulier dans un environnement de développement. les USdéveloppement, en particulier dans une Task Force USconfiguration.

S'il est effectué dans une configuration différente, le PanTesting doit être envisagé pour gérer les problèmes de WIP.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍