La gestion de projets en cascade sépare le développement et les tests en deux étapes différentes : les développeurs mettent au point une fonctionnalité, puis la « jettent par dessus le mur » à l'équipe d'assurance qualité afin que celle-ci la teste. Cette dernière élabore et exécute les plans de tests détaillés. Elle répertorie également les défauts tandis qu'elle vérifie minutieusement, dans les fonctionnalités existantes, la présence de régressions éventuellement causées par les nouvelles tâches.
Beaucoup d'équipes qui utilisent ces modèles en cascade ou d'autres modèles de tests traditionnels constatent qu'à mesure que le produit se popularise, le volume de tests augmente de façon exponentielle. Et l'équipe QA lutte invariablement pour tenir le rythme. Les responsables produit font alors face à un choix malvenu : retarder la livraison ou lésiner sur les tests. (Je vous laisse deviner l'option qui remporte l'adhésion 99 % du temps.) Entre-temps, le développement est passé à autre chose. Donc, non seulement la dette technique augmente, mais la gestion de chaque défaut requiert un changement de contexte coûteux entre deux portions de la base de code. La double peine.
Et, comme si cela ne suffisait pas, les équipes de QA sont généralement gratifiées en fonction du nombre de bugs qu'elles trouvent, ce qui met les développeurs sur la défensive. Et s'il existait une meilleure façon, à la fois pour les développeurs et l'équipe de QA, de réduire le nombre de bugs dans le code, tout en éliminant ces douloureux compromis que les Project Owners sont contraints de faire ? Globalement, les logiciels ainsi développés ne seraient-ils pas de meilleure qualité ?
Bienvenue à l'ère des tests Agile et DevOps.
Migrer des tests traditionnels aux tests agiles
L'objectif des équipes Agile et DevOps est de livrer de façon durable de nouvelles fonctionnalités de qualité. Cependant, les méthodologies de test traditionnelles ne cadrent tout simplement pas avec un framework Agile ou DevOps. Le rythme du développement nécessite une nouvelle approche pour garantir la qualité dans chaque build. Chez Atlassian, notre méthode de test est agile. Examinez attentivement notre approche de test avec Penny Wyatt, Senior QA Team Lead pour Jira Software.
À l'instar de l'amoncellement de dettes sur une carte bancaire, cela commence par une douleur presque imperceptible. Mais l'effet boule de neige est rapide et prive l'équipe de sa cruciale agilité. Chez Atlassian, pour lutter contre l'effet boule de neige de la dette technique, nous habilitons nos développeurs à devenir (ou plutôt, attendons d'eux qu'ils deviennent) d'excellents champions de la qualité. Nous estimons qu'ils apportent des compétences clés qui favorisent la qualité du produit :
- Les développeurs brillent dans la résolution des problèmes au moyen du code.
- Les développeurs qui créent leurs propres tests seront davantage sollicités pour les corriger en cas d'échec.
- Les développeurs qui comprennent les exigences liées aux fonctionnalités et leurs implications au regard des tests créent généralement un meilleur code.
Nous croyons que chaque user story du backlog nécessite à la fois un code pour les fonctionnalités et un code pour les tests automatisés. Certaines équipes assignent le code des fonctionnalités aux développeurs, tandis que l'équipe de tests prend en charge les tests automatisés. Mais nous trouvons plus efficace de demander à un même ingénieur de livrer l'ensemble.
Gérez différemment les bugs des nouvelles fonctionnalités et les régressions des fonctionnalités existantes. Si un bug apparaît pendant le développement, prenez le temps de comprendre l'erreur commise, corrigez-la, puis passez à autre chose. Si une régression survient (une fonctionnalité qui présente soudainement un problème alors qu'il n'y en avait pas auparavant), il est probable qu'elle se reproduise. Créez un test automatisé pour vous protéger contre cette régression à l'avenir.
Ce modèle ne signifie pas que les développeurs travaillent seuls. Il est également important de faire intervenir les ingénieurs en assurance qualité dans l'équipe. En effet, l'AQ apporte une perspective essentielle dans le développement d'une fonctionnalité. De plus, les ingénieurs expérimentés en assurance qualité savent où se cachent généralement les bogues et peuvent conseiller les développeurs sur les « pièges » probables.
Une touche humaine grâce aux tests exploratoires
Dans nos équipes de développement, les membres de l'équipe d'assurance qualité travaillent en binômes avec les développeurs sur les tests exploratoires, une pratique précieuse qui, pendant le développement, permet d'éliminer les bogues les plus sérieux. Comme pour la revue de code, nous avons constaté, avec cette pratique, des transferts de connaissances des tests dans l'ensemble de l'équipe de développement. Lorsque les développeurs deviennent de meilleurs testeurs, ils livrent un meilleur code dès le départ.
Mais les tests exploratoires ne sont-ils pas des tests manuels ? Pas du tout. Du moins, pas dans le sens de tests manuels sur les régressions. Les tests exploratoires procèdent d'une approche axée sur la pensée critique et basée sur les risques. Cette approche permet au testeur d'utiliser sa connaissance des risques, des détails de la mise en œuvre et des besoins du client. En déterminant ces éléments de façon plus précoce dans le processus de tests, le développeur ou l'ingénieur en assurance qualité peut identifier les problèmes de façon rapide et complète, sans recourir à des cas de tests exécutés par des scripts, à des plans de tests détaillés ou à des exigences. Nous trouvons cela beaucoup plus efficace que les tests manuels traditionnels. En effet, cela nous permet de répercuter les résultats des sessions de tests exploratoires dans le code original et les tests automatisés. Les tests exploratoires nous en disent également beaucoup plus sur l'utilisation de la fonctionnalité que les tests exécutés par des scripts.
La qualité, si l'on veut la préserver, nécessite un mélange de tests exploratoires et de tests automatisés. Au fur et à mesure du développement de nouvelles fonctionnalités, les tests exploratoires garantissent que le nouveau code respecte le standard de qualité de façon plus globale que les seuls tests automatisés. Ceci passe par la simplicité d'utilisation, l'attrait visuel et l'utilité générale des fonctionnalités, en plus des protections efficaces contre les régressions qu'offrent les tests automatisés.
Le changement peut être difficile, très difficile
Laissez-moi vous raconter une anecdote personnelle qui résume parfaitement mon parcours en matière de tests agiles. Au début de ma carrière, je dirigeais une équipe d'ingénieurs qui rechignait fortement à effectuer des tests automatisés. Elle estimait que c'était « le travail de l'assurance qualité ». Après plusieurs itérations de code rempli de bogues et après avoir entendu toutes les raisons imaginables pour lesquelles les tests automatisés risquaient de ralentir l'équipe, j'ai dû mettre fin à ce petit jeu. Dès lors, tout nouveau code allait devoir être soumis à des tests automatisés.
Après une seule itération, le code a commencé à s'améliorer. Et le développeur qui était le plus fermement opposé à la création de tests est, au final, devenu celui qui se mobilisait systématiquement lorsqu'un test échouait ! Lors des quelques itérations suivantes, les tests automatisés ont évolué, ils ont été adaptés à l'ensemble des navigateurs et ont amélioré notre culture du développement. Bien entendu, il fallait plus de temps pour sortir une fonctionnalité. Mais les bogues et les reprises du travail ont considérablement diminué. Au final, nous avons gagné énormément de temps.
Le changement est rarement facile. Mais comme pour tout ce qui vaut la peine, si vous pouvez vous retrousser les manches et créer vous-même de nouvelles habitudes, la seule question que vous vous poserez à la fin sera : « Pourquoi est-ce qu'on n'a pas fait cela plus tôt ? ».
