Meilleures pratiques sur la stratégie de test pour une équipe Scrum

Scrum moins le plan de test équivaut à POC sur les stéroïdes.

De nos jours, la plupart des projets réussis commencent par une preuve de concept (POC), une évaluation relativement petite d'une idée, où la technologie et le pack de fonctionnalités choisis seront d'abord vérifiés, évalués pour leur impact potentiel sur les utilisateurs professionnels, puis, une fois prouvés. digne d'investissement, une équipe de projet complète est chargée de concevoir et de livrer le produit complet et de le déployer en production.

C'est le cas parfait pour une équipe Scrum. L'équipe peut rapidement développer le prototype, en ajoutant de nouvelles fonctionnalités substantielles à chaque sprint, tandis que les utilisateurs professionnels peuvent observer en temps réel les progrès rapides et la façon dont l'idée est construite à partir de zéro en seulement 10 sprints. Cela laisse une forte impression (ce qui est de toute façon la cible principale du POC), mais il a aussi une propriété importante - des activités de test minimales ou inexistantes, et même penser au processus de test serait une blague directe.

Ce n'est pas une activité amusante au sein d'une équipe Scrum, et les gens aimeront surtout l'idée de développer sans processus pour les ralentir. C'est essentiellement ce que toute activité de test fera implicitement. Et qui veut une lenteur inutile pendant le temps dont nous avons le plus besoin pour impressionner l'utilisateur final ?

L'état qui se produit si l'équipe de projet continue de la même manière après la fin de la période POC est quelque chose que j'utilise pour appeler POC sur les stéroïdes - un système de production dont la taille et les fonctionnalités augmentent, mais qui se comporte toujours comme un POC - un produit complet en herbe avec vices cachés et cas d'angle inexplorés, n'attendant qu'un grave accident.

Mais avant qu'il ne se convertisse là-bas, l'équipe aura plus de mal de sprint en sprint à suivre les versions stables, car la résolution des problèmes de roulement ne deviendra que plus complexe.

Voici quelques techniques qui se sont avérées efficaces lorsque j'étais confronté à des problèmes similaires et qui, je pense, peuvent être qualifiées de meilleures pratiques pour mettre en œuvre des processus de test solides, sans toutefois trop encombrer la progression du développement - car c'est ce que nous voulons tous être une équipe Scrum.

Répartir la douleur

Par où d'autre devrions-nous commencer lorsqu'il s'agit de déranger inutilement que de diviser la douleur :).

Et ce que je veux dire par là, c'est créer un plan qui nécessitera une petite activité supplémentaire de la part des développeurs ici et là, mais qui contribuera grandement à l'objectif commun au fil du temps, de manière progressive mais cohérente.

#1. Développer le code de test unitaire pour chaque morceau de nouveau code créé

Si vous parvenez à convaincre vos équipes Scrum d'ajouter à sa clause Definition Of Done le développement de tests unitaires pour chaque nouveau code créé dans le sprint, alors dans une perspective à long terme, ce sera une grande réussite.

Les raisons sont assez évidentes :

Cela obligera les développeurs à réfléchir à divers chemins non standard du code. –

• Ces tests unitaires peuvent être connectés à des pipelines DevOps automatisés et exécutés à chaque déploiement dans l'environnement de développement ou de test. De plus, les métriques du pipeline peuvent être facilement exportées puis utilisées pour démontrer aux utilisateurs professionnels le pourcentage de couverture des cas de test directement liés au code source.

Le plus important est de commencer très tôt. Plus tard les tests unitaires commenceront à être développés, plus il deviendra distrayant pour les développeurs de les ajouter dans un sprint.

• Il faudra des efforts considérables pour développer des tests unitaires à rebours pour du code déjà existant. Certaines parties du code peuvent être créées par un autre développeur et la connaissance exacte de la façon dont cela devrait fonctionner dans chaque partie de code n'est pas exactement claire pour le développeur actuel. Dans certains cas, cela peut aller si loin que l'ajout d'un test unitaire au code modifié prendra plus de temps que le développement du changement de fonctionnalité pour le sprint (qui est un état que personne n'a calculé lors de la planification du sprint à coup sûr).

#2. Faire une routine d'exécution de toutes les parties des tests unitaires sur l'environnement de développement

Avant même de créer une demande d'extraction pour fusionner le nouveau code dans la branche Master, il doit être une activité standard de tester à la fois le code de fonctionnalité et le code de test unitaire sur l'environnement de développement. Ce faisant, il sera assuré que :

• Le code de test unitaire fonctionne réellement pour chaque partie (au final, c'est juste un autre code qui doit être vérifié). Cette étape est très souvent totalement sautée. On suppose en quelque sorte que si le test unitaire est de toute façon branché sur le pipeline DevOps, il sera finalement exécuté et testé quelque part par défaut. Cependant, cela ne fait que pousser les problèmes aux niveaux supérieurs des activités de sprint, où l'équipe a généralement moins de temps et plus de stress pour terminer chaque histoire engagée.
• Le nouveau code de fonctionnalité est testé par le développeur pour les fonctionnalités de base. Évidemment, on ne peut pas attendre de ce test que la fonctionnalité métier soit entièrement vérifiée, mais au moins ce test confirmera que le code se comporte comme le développeur l'a prévu (en ignorant, pour l'instant, le fait que la logique métier pourrait mal compris lors du développement).

#3. Attendez-vous à l'exécution des tests unitaires après la fusion du code dans la branche principale

C'est une chose d'avoir du code fonctionnel sur la branche locale (où personne d'autre que le propriétaire de la branche ne développe une nouvelle fonctionnalité), mais c'est une chose complètement différente d'avoir le même code qui fonctionne après la pull request et fusionne dans la branche master.

La branche principale contient des modifications d'autres membres de l'équipe Scrum, et même si les conflits sont résolus et que tout semble correct, le code après la fusion et la résolution des conflits est fondamentalement encore un morceau de code non testé, et il est risqué de l'envoyer plus loin sans vérifier d'abord ça marche toujours bien.

Donc, ce qui s'est avéré efficace ici, c'est simplement de demander d'exécuter les mêmes tests unitaires - déjà effectués précédemment sur l'environnement de développement - également sur l'environnement, qui est construit à partir de la version principale du code de branche.

Pour les développeurs, c'est peut-être une étape supplémentaire qu'ils doivent inclure dans leur vie, mais ce n'est pas un gros effort puisque, dans ce cas, rien de nouveau ne doit être inventé - il suffit de réexécuter ce qui a déjà été fait une fois.

Maintenant, cette étape pourrait être ignorée dans un cas particulier :

• Les tests unitaires automatisés dans les pipelines DevOps sont si complets qu'ils couvrent déjà l'ensemble des tests manuels exécutés en plus de cela.

Bien qu'il soit tout à fait possible d'atteindre cet état, je n'ai jamais connu un tel état dans la vie réelle. Il serait probablement même trop long pour les développeurs de créer des tests unitaires automatisés aussi détaillés. Il pourrait devenir facilement inacceptable pour le propriétaire du produit de laisser l'équipe consacrer autant de temps à cette activité, car cela aurait un impact explicite sur le nombre d'histoires livrées dans un sprint.

Cependant, la préférence pour le contenu du sprint ne doit jamais être une excuse pour ne pas faire les tests unitaires, voire les minimiser. En faisant cela, l'équipe se convertira à nouveau dans un état tel que le code manque trop de couverture de test unitaire, puis pour un rattrapage, il pourrait être déjà trop tard (encore une fois, l'effort plus élevé pour l'achèvement du test unitaire que le réel changement de code pour un sprint).

Pour toutes ces raisons, je recommanderais sans hésitation la ré-exécution des tests unitaires sur la version du code maître. C'est un effort si faible par rapport à la valeur qu'il apportera.

Il effectuera la vérification finale de la préparation de la branche principale pour la phase de test de la version. En outre, cela aidera à trouver la plupart des bogues techniques (par exemple, les bogues qui empêchent le code source d'être exécuté avec succès jusqu'à la fin), laissant pour la phase suivante se concentrer uniquement sur la vérification de la fonctionnalité métier.

Préparez-vous aux tests fonctionnels

Toutes les activités de test précédentes doivent aboutir à une conclusion spécifique : le code de la branche principale est exempt de bogues techniques et exécutable sans problème pour les flux fonctionnels de bout en bout.

C'est une phase qui peut être facilement couverte par une seule personne, et cette personne n'a même pas besoin d'avoir une formation technique.

En fait, c'est bien mieux si cela est exécuté par quelqu'un déconnecté des développeurs mais avec une connaissance fonctionnelle de ce à quoi les utilisateurs professionnels s'attendent à ce que le code se comporte. Il y a deux activités principales à réaliser :

#1. Test fonctionnel ciblé de nouvelles histoires de sprint

Chaque sprint doit idéalement apporter une nouvelle fonctionnalité (incrément d'objectif de sprint) qui était auparavant inexistante, et donc elle doit être vérifiée. Il est important de s'assurer que le nouveau logiciel fonctionne dans une telle mesure que les utilisateurs professionnels sont heureux de l'avoir maintenant, car ils l'attendaient évidemment avec impatience tout le dernier sprint au minimum :).

C'est une expérience si triste lorsque la fonctionnalité (longue) promise est enfin annoncée pour être publiée, pour découvrir l'autre jour qu'elle ne fonctionne pas bien.

Par conséquent, il est crucial de tester correctement les nouvelles fonctionnalités de sprint. Afin d'en faire un succès, il est recommandé de rassembler à l'avance des cas de test importants auprès des parties prenantes concernées (soit du propriétaire du produit, soit même des utilisateurs finaux) et de dresser une liste de tous ces cas de test nécessaires pour le contenu à l'intérieur. le sprint.

Cela peut sembler écrasant à première vue, mais d'après mon expérience, c'est à nouveau totalement gérable par une seule personne. Étant donné que les sprints sont généralement assez courts (comme une courte période de deux semaines), il n'y a presque jamais trop de nouveau contenu de toute façon, car le sprint contient également des activités supplémentaires telles que des histoires de dette technique, de la documentation, des histoires de conception/spike, etc.

Les cas de test sont ensuite exécutés dans le but de vérifier avant tout la fonctionnalité souhaitée. Si un problème survient avec les résultats, seul le développeur concerné est approché (celui qui possède les modifications liées à ce défaut particulier) pour résoudre le problème, espérons-le rapidement.

De cette façon, les développeurs passeront un minimum de temps sur les tests fonctionnels et pourront toujours se concentrer sur les activités qu'ils aiment le plus.

#2. Exécution des cas de test de régression

L'autre partie des tests fonctionnels consistera à s'assurer que tout ce qui a fonctionné jusqu'à présent fonctionnera également après la prochaine version. C'est à cela que servent les tests de régression.

Les cas de test pour les tests de régression sont meilleurs s'ils sont régulièrement maintenus et revisités avant chaque version. Sur la base des spécificités concrètes du projet, il est préférable de les garder simples tout en couvrant la majorité des fonctionnalités de base et des flux de bout en bout importants qui traversent l'ensemble du système.

Habituellement, chaque système a de tels processus qui touchent de nombreux domaines différents, ce sont les meilleurs candidats pour les cas de test de régression.

Dans certains cas, les tests de régression couvrent même implicitement les nouvelles fonctionnalités du sprint, par exemple, si la nouvelle histoire du sprint modifie une partie particulière du flux existant.

Ainsi, dans la plupart des cas, il n'est pas du tout très complexe de réaliser des tests de régression parallèlement aux tests de fonctionnalité des nouvelles histoires de sprint, surtout si cela est fait régulièrement avant chaque sortie de production, et que la périodicité des sorties de production n'est pas trop petite.

Insistez pour exécuter des tests d'assurance qualité avant chaque version de production

Le test d'assurance qualité (QA) est la dernière étape avant la mise en production, et souvent ce test est ignoré car sans importance. Surtout si l'équipe Scrum est gérée de manière agressive pour le nouveau contenu.

Même les utilisateurs professionnels diront qu'ils sont intéressés par les nouvelles fonctionnalités et non pas tant par la préservation de la fonctionnalité ou le maintien d'un nombre de défauts faible. Mais encore une fois - avec le temps, c'est la principale raison pour laquelle l'équipe de développement devra éventuellement ralentir, et les utilisateurs professionnels n'obtiendront de toute façon pas ce qu'ils demandent.

Un test d'assurance qualité doit être exécuté uniquement par des personnes extérieures à l'équipe Scrum, idéalement par des utilisateurs métier eux-mêmes dans un environnement dédié, aussi proche que possible de la production future. Alternativement, le propriétaire du produit peut remplacer ici les utilisateurs finaux.

Dans tous les cas, cela devrait être un test propre et fonctionnel du point de vue de l'utilisateur final, sans aucun lien avec l'équipe de développement Scrum. Il présentera une vue finale du produit et sera utilisé d'une manière que personne de l'équipe Scrum n'avait prévue (ce n'est pas du tout un cas idéal, mais cela peut certainement arriver). Il est encore temps pour les corrections de dernière minute.

Alternativement, il pourrait devenir clair que les attentes n'étaient pas bien comprises par l'équipe Scrum, et dans ce cas, au moins nous pouvons nous mettre d'accord sur un plan de suivi, encore bien avant la sortie de production proprement dite. Ce n'est encore une fois pas un cas idéal, mais c'est encore mieux comme admettre l'échec juste après avoir signalé une sortie de production réussie.

Où aller ensuite à partir d'ici ?

L'application de ces pratiques au travail Scrum quotidien peut sérieusement vous amener à des habitudes de publication de sprint plus stables et prévisibles, sans retarder les versions de production ou passer tout le sprint à préparer la prochaine version, ou même sans forcer tous les membres de l'équipe Scrum à faire quelque chose qu'ils ne font pas. Je n'aime pas vraiment ou je ne sais pas comment faire efficacement de toute façon pour la majorité du sprint, c'est-à-dire.

Mais vous n'avez sûrement pas besoin de vous arrêter ici.

L'inclusion des tests de performance est un sujet à nommer ici. Celles-ci sont souvent ignorées ou jugées inutiles, grattant au premier tour de "l'optimisation des activités Scrum". J'ai cependant toujours douté de la façon dont on peut s'attendre à ce que le système de production évolue dans le temps s'il n'est pas régulièrement contrôlé pour ses performances.

Monter d'un niveau signifie aussi la mise en place de tests automatisés.

J'ai déjà couvert un groupe de tests automatisés (tests unitaires dans les pipelines). Cependant, vous pouvez développer des tests de régression complets de bout en bout entièrement automatisés et exécutés par eux-mêmes après chaque déploiement dans l'environnement de test. Cela libérerait encore plus l'équipe de développement Scrum, mais cela nécessite une équipe dédiée pour développer et maintenir de tels tests automatisés. Cela deviendrait un travail constant, car chaque fois que le code de production change, certains tests automatisés existants peuvent devenir invalides et doivent donc être mis à jour pour continuer à fonctionner dans les pipelines. C'est un effort que seuls quelques-uns sont prêts à payer, mais les avantages pour l'équipe de développement Scrum seraient cependant considérables.

Ce sont des sujets qui vont bien au-delà de la portée de cet article et qui déterminent le bon calendrier et le bon timing pour chaque type de test mentionné ici - afin que vous puissiez le faire dans une fenêtre de sprint. Je serai ravi de plonger la prochaine fois !