Une route vers de meilleurs tests agiles

Le rapport annuel sur la qualité mondiale créé par Capgemini montre que 42 % des personnes interrogées citent un "manque d'expertise professionnelle en matière de test" comme un défi dans l'application des tests au développement Agile. Alors que l'avènement d'Agile a entraîné une augmentation de la vitesse des itérations pour le développement de logiciels, dans certains cas, cela s'est fait au détriment de la qualité.

La concurrence féroce fait pression sur les équipes pour qu'elles fournissent constamment de nouvelles mises à jour de produits, mais cela a parfois son propre coût, notamment une attention réduite aux tests. Certains, comme Rob Mason, vont encore plus loin et affirment qu'Agile est en train de tuer les tests logiciels. Récemment, Facebook a changé sa devise de "bouger vite et casser des choses" à "bouger vite avec une infrastructure stable" pour tenter de résoudre les tentations de sacrifier la qualité.

Alors, comment mieux intégrer les tests dans le nouveau monde du développement logiciel Agile ? Tests agiles.

Les tests traditionnels sont assez lourds et dépendent de beaucoup de documentation. Le test Agile est une approche du processus de test qui imite les principes du développement logiciel Agile selon lequel :

• Les tests sont effectués beaucoup plus souvent,
• Les tests reposent moins sur la documentation et plus sur la collaboration des membres de l'équipe, et
• Certaines activités de test sont entreprises non seulement par des testeurs mais aussi par des développeurs.

Au cours des sept dernières années, j'ai fait passer de nombreuses équipes aux tests Agile et j'ai travaillé côte à côte avec des testeurs pour aider leurs processus à s'adapter à la nouvelle méthodologie. Dans cet article, je vais partager quelques-uns des conseils les plus percutants que j'ai appris tout au long de mon cheminement vers de meilleurs tests Agile. Bien qu'il soit naturel d'avoir des frictions entre vitesse et qualité dans les pratiques Agiles, cet article couvrira quelques techniques qui peuvent être utilisées pour augmenter la qualité des tests sans compromettre l'agilité. La plupart des suggestions décrites ici nécessiteront l'implication de l'équipe, il sera donc avantageux que les développeurs et les testeurs participent à la planification.

Formaliser un processus de cycle de test de version

L'un des problèmes liés aux tests est l'absence de cycle de test de version, l'absence de calendrier de publication ou des demandes de test irrégulières. Les demandes de test à la demande compliquent le processus d'assurance qualité, en particulier si les testeurs gèrent plusieurs projets.

De nombreuses équipes ne font qu'un seul build après chaque sprint, ce qui n'est pas idéal pour les projets Agile. Passer à des versions hebdomadaires pourrait être bénéfique, en passant progressivement à plusieurs versions par semaine. Idéalement, les builds de développement et les tests devraient avoir lieu quotidiennement, ce qui signifie que les développeurs poussent le code vers le référentiel tous les jours et que les builds sont programmés pour s'exécuter à une heure précise. Pour aller plus loin, les développeurs pourraient déployer un nouveau code à la demande. Pour mettre cela en œuvre, les équipes peuvent utiliser un processus d'intégration et de déploiement continus (CI/CD). CI/CD limite la possibilité d'échec d'une construction le jour d'une version majeure.

Lorsque CI/CD et l'automatisation des tests sont combinés, une détection précoce des bogues critiques est possible, ce qui permet aux développeurs d'avoir suffisamment de temps pour corriger les bogues critiques avant la publication prévue du client. L'un des principes d'Agile stipule que le logiciel fonctionnel est la principale mesure du progrès. Dans ce contexte, un cycle de release formalisé rend le processus de test plus agile.

Autonomisez les testeurs avec des outils de déploiement

L'un des points de friction courants pour les tests est le déploiement du code dans un environnement de test. Ce processus dépend de l'infrastructure technique que votre équipe peut ne pas être en mesure d'affecter. Cependant, s'il y a une certaine flexibilité, des outils peuvent être créés pour les personnes non techniques comme les testeurs ou les chefs de projet qui leur permettraient de déployer la base de code mise à jour pour se tester eux-mêmes.

Par exemple, dans une de mes équipes, nous utilisions Git pour le contrôle de version et Slack pour la communication. Les développeurs ont créé un Slackbot qui avait accès à Git, aux scripts de déploiement et à une machine virtuelle. Les testeurs ont pu envoyer un ping au bot avec un nom de branche acquis auprès de GitHub ou Jira et le faire déployer dans un environnement intermédiaire.

Cette configuration a libéré beaucoup de temps pour les développeurs tout en réduisant le gaspillage de communication et les interruptions constantes lorsque les testeurs devaient demander aux développeurs de déployer une branche pour les tests.

Expérimentez avec TDD et ATDD

Le développement piloté par les tests (TDD) est un type de processus de développement logiciel qui met l'accent sur la qualité. Traditionnellement, un développeur écrit du code, puis quelqu'un le teste et signale si des bogues ont été trouvés. Dans TDD, les développeurs écrivent d'abord des tests unitaires avant même d'écrire du code qui compléterait une user story. Les tests échouent initialement jusqu'à ce que le développeur écrive la quantité minimale de code pour réussir les tests. Après cela, le code est refactorisé pour répondre aux exigences de qualité de l'équipe.

Le développement piloté par les tests d'acceptation (ATDD) suit une logique similaire à celle du TDD mais, comme son nom l'indique, se concentre sur les tests d'acceptation. Dans ce cas, des tests de recette sont créés en amont du développement en collaboration avec les développeurs, les testeurs et le demandeur (client, product owner, business analyst, etc.). Ces tests aident tous les membres de l'équipe à comprendre les exigences du client avant l'écriture de tout code.

Des techniques telles que TDD et ATDD rendent les tests plus agiles en déplaçant les procédures de test aux premières étapes du cycle de développement. Lors de la rédaction de scénarios de test dès le début, les développeurs doivent très bien comprendre les exigences. Cela minimise la création de code inutile et résout également toutes les incertitudes du produit au début du cycle de développement. Lorsque des questions ou des conflits sur les produits n'apparaissent que dans les étapes ultérieures, le temps et les coûts de développement augmentent.

Découvrez les inefficacités en suivant le mouvement des cartes de tâches

Dans une de mes équipes, nous avions un développeur qui était extrêmement rapide, surtout avec de petites fonctionnalités. Il recevait beaucoup de commentaires lors de la révision du code, mais notre maître Scrum et moi avons considéré cela comme un manque d'expérience. Cependant, au fur et à mesure qu'il commençait à coder des fonctionnalités plus complexes, les problèmes devenaient plus apparents. Il avait développé un modèle de passage du code aux tests avant qu'il ne soit complètement prêt. Ce modèle se développe généralement lorsqu'il y a un manque de transparence dans le processus de développement, par exemple, il n'est pas clair combien de temps différentes personnes consacrent à une tâche donnée.

Parfois, les développeurs précipitent leur travail dans le but de publier les fonctionnalités le plus rapidement possible et de « sous-traiter » la qualité aux testeurs. Une telle configuration ne fait que déplacer le goulot d'étranglement plus loin dans le sprint. L'assurance qualité (AQ) est le filet de sécurité le plus important dont dispose l'équipe, mais cela peut signifier que l'existence de l'AQ donne aux développeurs la possibilité de renoncer aux considérations de qualité.

De nombreux outils de gestion de projet modernes ont la capacité de suivre le mouvement des cartes de tâches sur un tableau Scrum ou Kanban. Dans notre cas, nous avons utilisé Jira pour analyser ce qui s'est passé avec les tâches du développeur en question et avons fait des comparaisons avec d'autres développeurs de l'équipe. Nous avons découvert que :

• Ses tâches passaient presque deux fois plus de temps dans la colonne des tests de notre conseil d'administration ;
• Ses tâches seraient beaucoup plus souvent renvoyées de QA pour un deuxième ou un troisième tour de réparation.

Ainsi, à part le fait que les testeurs devaient consacrer plus de temps à ses tâches, ils devaient également le faire plusieurs fois. Notre processus opaque donnait l'impression que le développeur était vraiment rapide ; cependant, cela s'est avéré faux lorsque nous avons pris en compte le temps de test. Déplacer les user stories d'avant en arrière n'est évidemment pas une approche allégée.

Pour résoudre ce problème, nous avons commencé par avoir une discussion honnête avec ce développeur. Dans notre cas, il n'était tout simplement pas conscient du caractère préjudiciable de son rythme de travail. C'était simplement la façon dont il s'était habitué à travailler dans son ancienne entreprise, qui avait des exigences de qualité inférieures et un plus grand pool de testeurs. Après notre conversation et à l'aide de quelques séances de programmation en binôme avec notre Scrum master, il est progressivement passé à une approche de développement de meilleure qualité. En raison de ses capacités de codage rapides, il était toujours très performant, mais le «gaspillage» supprimé du processus d'AQ a rendu l'ensemble du processus de test beaucoup plus agile.

Ajouter l'automatisation des tests à l'ensemble de compétences de l'équipe QA

Les tests dans les projets non Agile impliquent des activités telles que l'analyse des tests, la conception des tests et l'exécution des tests. Ces activités sont séquentielles et nécessitent une documentation détaillée. Lorsqu'une entreprise passe à Agile, le plus souvent, la transition se concentre principalement sur les développeurs et pas autant sur les testeurs. Ils arrêtent de créer une documentation complète (un pilier des tests traditionnels) mais continuent à effectuer des tests manuels. Cependant, les tests manuels sont lents et ne peuvent généralement pas faire face aux boucles de rétroaction rapides d'Agile.

L'automatisation des tests est une solution populaire à ce problème. Les tests automatisés facilitent grandement le test de nouvelles et petites fonctionnalités, car le code de test peut s'exécuter en arrière-plan pendant que les développeurs et les testeurs se concentrent sur d'autres tâches. De plus, comme les tests sont exécutés automatiquement, la couverture des tests peut être beaucoup plus importante par rapport aux efforts de test manuels.

Les tests automatisés sont des morceaux de code logiciel similaires à la base de code qui est testée. Cela signifie que les personnes qui écrivent des tests automatisés auront besoin de compétences techniques pour réussir. Il existe de nombreuses variantes de la manière dont les tests automatisés sont mis en œuvre dans différentes équipes. Parfois, les développeurs assument eux-mêmes le rôle de testeurs et augmentent la base de code de test à chaque nouvelle fonctionnalité. Dans d'autres équipes, les testeurs manuels apprennent à utiliser les outils d'automatisation des tests ou un testeur technique expérimenté est embauché pour automatiser le processus de test. Quelle que soit la voie empruntée par l'équipe, l'automatisation conduit à des tests beaucoup plus agiles.

Gérer les priorités de test

Avec le développement de logiciels non Agile, les testeurs sont généralement affectés par projet. Cependant, avec l'avènement d'Agile et de Scrum, il est devenu courant que les mêmes professionnels de l'assurance qualité opèrent sur plusieurs projets. Cette responsabilité qui se chevauche peut créer des conflits dans les horaires et faire en sorte que les testeurs manquent des cérémonies critiques lorsqu'un testeur donne la priorité aux tests de version d'une équipe par rapport à la session de planification de sprint d'une autre.

La raison pour laquelle les testeurs travaillent parfois sur plusieurs projets est évidente : il y a rarement un flux constant de tâches de test pour remplir un rôle à temps plein. Par conséquent, il peut être difficile de convaincre les parties prenantes d'affecter une ressource de test dédiée à une équipe. Cependant, il existe certaines tâches raisonnables qu'un testeur peut effectuer pour combler son temps d'arrêt lorsqu'il ne s'engage pas dans des activités de test.

Assistance clientèle

Une configuration possible consiste à demander au testeur de passer son temps d'arrêt de sprint à aider l'équipe de support client. En faisant constamment face aux problèmes des clients, le testeur a une meilleure compréhension de l'expérience utilisateur et comment l'améliorer. Ils peuvent contribuer aux discussions lors des séances de planification. De plus, ils deviennent plus attentifs lors de leurs activités de test car ils sont mieux familiarisés avec la façon dont les clients utilisent réellement leur logiciel.

Gestion des produits

Une autre technique pour gérer les priorités des testeurs consiste essentiellement à en faire des chefs de produit juniors qui effectuent des tests manuels. Il s'agit également d'une solution viable pour remplir le temps libre d'un testeur, car les chefs de produit juniors passent beaucoup de temps à créer des exigences pour les user stories et ont donc une connaissance intime de la plupart des tâches.

Automatisation des tests

Comme nous en avons discuté précédemment, les tests manuels sont souvent inférieurs à l'automatisation. Dans ce contexte, la poussée vers l'automatisation peut être associée au fait qu'un testeur consacre toute son attention à l'équipe et utilise son temps libre pour apprendre à travailler avec des outils d'automatisation des tests comme Selenium.

Résumé : tests agiles de qualité

Rendre les tests plus agiles est une fatalité à laquelle de nombreuses équipes de développement logiciel sont désormais confrontées. Cependant, la qualité ne doit pas être compromise en adoptant un état d'esprit « testez aussi vite que possible ». Il est impératif qu'une transition Agile inclue un passage aux tests Agile, et il existe plusieurs façons d'y parvenir :

• Formaliser un processus de cycle de test de version.
• Offrez aux testeurs des outils de déploiement.
• Expérimentez le développement piloté par les tests et le développement piloté par les tests d'acceptation.
• Découvrez les inefficacités en suivant le mouvement des cartes de tâches.
• Ajoutez l'automatisation des tests aux compétences de l'équipe QA.
• Gérer les priorités des testeurs.

Chaque année, les logiciels s'améliorent et les attentes des utilisateurs augmentent. De plus, à mesure que les clients s'habituent aux produits de haute qualité des grandes marques de logiciels comme Google, Apple et Facebook, ces attentes se transfèrent également dans d'autres produits logiciels. Ainsi, l'accent mis sur la qualité devrait être encore plus important dans les années à venir. Ces améliorations du processus de test et de développement global peuvent rendre les tests plus agiles et garantir un haut niveau de qualité des produits.