Pourquoi nous déplaçons les tests vers la gauche : un cycle de développement logiciel qui n’évolue pas

C’est la première de deux parties.

Les tests Shift Left consistent à déplacer les tests plus tôt dans le processus de développement. Dans un cycle de développement traditionnel, les tests ont souvent lieu après l’achèvement d’une fonctionnalité ou même à la fin de la phase de développement. Shift Left Testing remet cela en question en intégrant les activités de test dès le début et tout au long du processus de développement.

Commençons par expliquer pourquoi nous avons choisi l’option de déplacement vers la gauche, car ce n’est pas le seul moyen de résoudre les problèmes de mise à l’échelle avec votre cycle de vie de développement logiciel (SDLC).

Un conte aussi vieux que le temps : un SDLC qui n’évolue pas

Avant de décider de déplacer davantage de tests vers le développement du processus, discutons des raisons pour lesquelles les dirigeants prendraient cette décision en premier lieu.

Il existe une lecture cynique du « shift left » qui signifie « faire travailler les gens plus mais les payer le même ». Une équipe de développement stressée pourrait se rebeller à l’idée d’ajouter davantage de préoccupations à son agenda. Mais la véritable motivation pour déplacer les tests vers la gauche est la frustration liée à un cycle de publication de logiciels dans une impasse, les développeurs étant obligés de changer de contexte et jamais autorisés à entrer dans un état de flux et une vitesse de développement glaciale.

Une entreprise en pleine expansion dont le processus de test ne l’est pas

Imaginez que vous travaillez dans une entreprise qui dépasse le stade du démarrage. Vous vous souvenez tous d’une époque où les fonctionnalités étaient disponibles en quelques semaines, voire quelques jours, mais cette époque est révolue depuis longtemps. Désormais, plusieurs équipes tentent de publier des branches en même temps, et le contrôle qualité s’efforce de détecter les problèmes avant de les lancer en production.

Pire encore, la complexité de l’architecture des microservices signifie que les développeurs ne peuvent pas effectuer efficacement des tests d’intégration avant d’expédier le code pour le contrôle qualité. On parle beaucoup de l’amélioration des tests de contrats, mais encore une fois, les choses évoluent rapidement et les estimations pour rédiger des contrats intra-service clairs et les refactoriser en conséquence prendraient des mois. Pendant ce temps, les développeurs sont obligés d’écrire des tests unitaires et de créer des simulations grossières pour des services externes tels que des prestataires de paiement et même pour les services d’autres équipes. Cela conduit à plus de surprises lorsque le code est déployé dans des environnements de pré-version comme le staging.

Le choix de déplacer les tests vers la gauche

Nos responsables de l’ingénierie sont donc confrontés à un choix : comment améliorer la vitesse des développeurs tout en envoyant moins de bogues en production ? Vous avez deux options :

• Augmentez l’équipe d’assurance qualité et développez les ressources pour leur environnement de test/stade, afin qu’ils puissent effectuer plus de tests plus rapidement.

Ce n’est pas un choix terriblement évolutif. Les équipes sont déjà parfois en conflit sur la question de savoir qui doit déployer sur le terrain et combien de temps elles doivent réserver l’environnement. De plus, même avec plus d’ingénieurs QA, vous obligez toujours les développeurs à écrire du code, à exécuter des tests limités, à pousser puis à attendre qu’un être humain réécrive les problèmes détectés. Le résultat est un cycle de rétroaction en « boucle externe » dans lequel les développeurs doivent soit suspendre tout leur travail jusqu’à ce qu’ils obtiennent un retour d’assurance qualité, soit changer de contexte entre deux branches alors qu’ils tentent de travailler sur la fonctionnalité suivante tout en revenant en arrière et en trouvant des problèmes avec la dernière chose qu’ils ont poussée. . Même avec un budget illimité pour l’équipe QA, cela ne pourra certainement pas s’adapter à des centaines de développeurs.

Développer l’assurance qualité n’est pas une alternative au déplacement vers la gauche

L’assurance qualité joue un rôle majeur dans la vision stratégique et les décisions d’architecture des tests, car une équipe d’ingénierie déplace les tests vers la gauche. Mais la quête visant à garantir le succès d’un plus grand nombre de versions n’est pas parfaitement servie par le simple élargissement de l’équipe d’assurance qualité. Pourquoi donc?

• Comme les développeurs n’effectuent que des tests de base avant de fusionner le code, il est probable que le contrôle qualité découvre des bogues d’intégration triviaux.

Cette liste d’attributs est-elle un tableau ou un objet ? Et ce localisateur est-il indexé 0 ou non ? Ces petites erreurs d’intégration peuvent bloquer une version lorsque le contrôle qualité les teste. Au lieu qu’un développeur découvre de petits problèmes avec son propre code et corrige rapidement les erreurs, le contrôle qualité est désormais tenu de documenter et de communiquer le problème. Pire encore, lorsque le contrôle qualité ne sait pas avec qui communiquer :

• Les équipes d’assurance qualité écrivent généralement des tests de bout en bout qui testent les flux métier/utilisateurs. Si l’un de ces tests échoue, il n’est pas clair à qui attribuer le problème, car le flux pourrait toucher plusieurs services frontend et backend.

En tant que développeur, vous effectuez des mises à jour user_state_controller, mais en tant que responsable du contrôle qualité, vous testez peut-être des éléments tels que « l’utilisateur peut mettre à jour sa connexion ». Il ne s’agit pas d’un décalage, car les équipes ont des objectifs différents. Mais lorsque le contrôle qualité détecte des erreurs dans un flux d’utilisateurs, il ne sait pas nécessairement à qui s’adresser en matière de développement serait la meilleure personne à qui parler. Cela entraîne des retards supplémentaires.

• La cadence à laquelle exécuter les tests n’est pas claire. Le contrôle qualité doit-il effectuer des tests quotidiennement ? Une fois que chaque pull request a été fusionnée ? Étant donné que la suite de tests est susceptible d’être volumineuse, il n’est pas pratique d’exécuter l’intégralité de la suite pour chaque validation.

Sans une équipe d’ingénieurs pour déterminer le meilleur ensemble de tests à exécuter, le contrôle qualité finit par exécuter les tests à une cadence réduite et ne détecter les problèmes que dans de grands groupes.

• Les développeurs connaissent des cycles de débogage très lents lorsque les tests échouent lors de la phase d’assurance qualité. Lorsque plusieurs commits sont testés ensemble, il n’est pas clair lequel est le commit incriminé.

Il s’agit d’une analyse de base qui, à mon avis, mérite plus de discussion : exécuter une grande suite de tests par une équipe d’assurance qualité est un moyen attrayant de s’assurer que tout fonctionne comme prévu de bout en bout. Mais les tests haute fidélité doivent également être effectués à haute fréquence. Dans le cas contraire, nous perdons les avantages fondamentaux du contrôle de code source : sans tests exécutés pour chaque validation, nous perdons les restaurations et les correctifs faciles. C’est l’une des nombreuses façons dont les tests « shift left » constituent un retour à une norme plus ancienne : les développeurs devraient être en mesure de savoir immédiatement si leur groupe de modifications actuel a cassé quelque chose. S’appuyer sur le contrôle qualité pour détecter les problèmes du premier coup signifie que vous parcourez une longue liste d’échecs en essayant de déterminer lesquels ont été causés par quel commit.

• Ce processus devient alors davantage un modèle en cascade où le développement et l’assurance qualité sont des phases distinctes et séquentielles. C’est le contraire d’une approche agile qui présente des avantages évidents.

Encore une fois, nous parlons d’une régression par rapport aux normes de codage et de livraison de 2005. Le modèle en cascade rend impossible une véritable livraison continue en production.

Une idée essentielle ici est que le contrôle qualité étant le seul à détecter les bogues, cela prive vos ingénieurs de pouvoir.

Donner du pouvoir à vos ingénieurs

Même sans les préoccupations des dirigeants concernant l’impact sur la vitesse, vous pouvez imaginer qu’une configuration dans laquelle la plupart des commentaires proviennent de la boucle externe peut être frustrante et douloureuse pour les ingénieurs. Mon propre ego mis à part, je ne veux pas pousser du code en lequel j’ai peu confiance. Cela nous amène à la deuxième option :

• Déplacez les tests vers la gauche, donnez aux développeurs le pouvoir d’exécuter des tests d’intégration ou même de bout en bout quelques minutes après l’écriture de leur code et assurez-vous que rien n’est soumis au contrôle qualité pour la pré-version sans une certitude de 95 % que tout fonctionne.

Dans ce scénario, casser des choses en tant que développeur peut à nouveau s’avérer amusant : nous expérimentons, voyons ce que les autres services peuvent prendre en charge et ne poussons que ce dont nous savons qu’il fonctionne. L’assurance qualité joue toujours un rôle majeur dans cette conception, mais son rôle consiste moins à tester manuellement et à trouver des bogues individuels. L’équipe d’assurance qualité devient plutôt un leader stratégique dans la définition de la stratégie d’automatisation, la sélection des frameworks de test et permettant aux développeurs d’avoir plus confiance dans leur code. Les tests étant accessibles quotidiennement à chaque ingénieur, de nombreux autres tests seront écrits et exécutés, mais leurs commentaires seront directement transmis aux développeurs via une boucle interne de commentaires.

Déplacer les tests vers la gauche est le retour d’un système plus ancien et meilleur

Lors d’une récente discussion au sein d’un groupe de café Lean sur l’ingénierie des plateformes, une idée m’est restée en tête, mentionnée par quelques participants :

« Les microservices présentent de nombreux avantages, mais les microservices sont beaucoup plus difficiles à tester. Ce problème est si grave que de nombreuses équipes ne voient pas de réel bénéfice dans les microservices.

J’ai déjà écrit à ce sujet, mais pour résumer : à l’ère des monolithes, il existait souvent un moyen de faire fonctionner l’ensemble du système, ou un fac-similé, sur votre ordinateur portable avec un minimum de friction. Cela signifiait que des tests importants pouvaient avoir lieu au moment même du développement.

Donc vraiment, quand nous parlons de déplacer les tests vers la gauche, nous parlons de les déplacer dos. Nous avons toujours un rôle pour les équipes d’assurance qualité, mais nous souhaitons remettre les premières séries de tests entre les mains des ingénieurs qui écrivent la fonctionnalité.

L’assurance qualité a toujours un rôle majeur

Dans la suite de cet article, j’écrirai sur le rôle que le contrôle qualité joue et continuera de jouer à mesure que vous transférez la responsabilité de l’exécution des tests à vos équipes de développement. En bref, le contrôle qualité a toujours un rôle majeur à jouer et en fera beaucoup plus, pas moins, lorsque les développeurs exécuteront davantage de vos tests. Si vous souhaitez discuter de cet article et des idées de tests de décalage à gauche, rejoignez-nous dans Signadot Slack. Nous serions ravis d’entendre vos idées !

Nonica Mellifera (Elle/Elle) a été développeur pendant sept ans avant de se lancer dans les relations avec les développeurs. Elle se spécialise dans les charges de travail conteneurisées, l’ingénierie sans serveur et le cloud public. Nonica est depuis longtemps un défenseur des normes ouvertes et a donné des conférences et des ateliers sur…

Lire la suite de Nonica Mellifera