Tests en boîte noire : éléments essentiels pour les équipes logicielles modernes

Introduction

Il y a cinq ans, l’expédition une fois par mois semblait rapide. Pour de nombreuses équipes, c’était le cas. Maintenant, cette même cadence vous qualifie de lente. Personne n’a décidé de conserver les anciennes pratiques de test. Ils n’ont tout simplement jamais été mis à jour. Les déploiements sont devenus plus rapides. Les services se sont séparés. L’approche de test de l’ère des versions mensuelles s’est imposée car personne n’avait prévu de réunion pour la reconsidérer.

Ce qui n’a pas automatiquement rattrapé son retard, c’est la philosophie des tests. Les tests en boîte noire en particulier occupent une position intéressante. Les tests en boîte noire, en tant que concept, sont antérieurs à la plupart des infrastructures sur lesquelles les équipes modernes fonctionnent. L’idée n’a pas changé. Ce qui a changé, c’est tout autour : la fréquence de déploiement, l’architecture, les outils, le rythme. Insérer l’ancienne idée dans le nouveau contexte sans faire d’ajustements est l’endroit où la plupart des équipes se trompent.

Pour trouver la bonne solution, il faut être honnête sur ce qu’est réellement le test en boîte noire. Supprimez la définition formelle et vous obtenez ceci : quelqu’un qui n’a pas construit la chose essaie de l’utiliser. Pas d’accès au code. Aucune connaissance de la manière dont cela a été mis en œuvre. Juste l’interface, la documentation de ce qu’il devrait faire et la volonté d’essayer des choses que les gens qui l’ont construit n’auraient jamais pensé essayer.

Les tests unitaires ne fonctionnent pas de cette façon. Le développeur qui rédige le test sait exactement quelle fonction est exercée et pourquoi. Les tests d’intégration ne fonctionnent pas de cette façon non plus. L’ingénieur qui prépare le test sait comment les composants se connectent et ce que leur interaction a été conçue pour produire. La révision du code ne le fait certainement pas. Chacune de ces pratiques se déroule dans les limites des connaissances des personnes qui ont construit l’objet testé.

Les tests en boîte noire sont la seule pratique qui sort délibérément de cette limite. C’est ce qui fait qu’il entre dans une catégorie différente de problèmes.

La catégorie d’échecs découverts par les tests de la boîte noire

Voici ce que les tests en boîte noire révèlent que d’autres méthodes continuent de manquer.

Un développeur qui teste son propre code, qu’il s’en rende compte ou non, le teste toujours par rapport à une carte qu’il a lui-même dessinée. Ils savent où mènent les chemins. Ils savent quelles entrées sont judicieuses. Ils savent quels cas extrêmes ils ont pris en compte et lesquels, selon eux, étaient trop peu probables pour s’en soucier. Cette carte façonne chaque test qu’ils exécutent, ce qui signifie qu’elle façonne également chaque échec qu’ils ne détectent pas.

Les utilisateurs n’ont pas cette carte. Une personne tape un numéro de téléphone dans le champ du code postal parce qu’elle n’y prêtait pas attention. Un autre appuie sur le bouton de retour à mi-chemin du paiement, puis essaie de reprendre là où il s’était arrêté. Quelqu’un d’autre ouvre le formulaire, est invité à une réunion, revient quatre-vingt-dix minutes plus tard et clique sur Soumettre. Aucune de ces choses n’est déraisonnable à faire. Aucun d’entre eux ne figure dans le plan de test du développeur.

Les tests en boîte noire donnent à ces comportements une place systématique dans le processus. Pas une seule fois, pas de manière informelle, mais à des points définis dans le processus de livraison.

Au début de la vie d’une fonctionnalité, avant sa fusion, quelqu’un l’exerce de l’extérieur. Pas de coup d’œil à la mise en œuvre. Juste le comportement. Est-ce qu’il fait ce qu’il dit ? Que se passe-t-il sur les bords ? Cela permet de combler les écarts de comportement alors qu’il est encore peu coûteux de les combler.

Lorsque les fonctionnalités sont combinées, l’image change. Deux éléments qui fonctionnent bien seuls peuvent échouer ensemble d’une manière qu’aucun des deux tests n’avait anticipée. Habituellement, cela se résume à un état partagé ou à des hypothèses que chaque fonctionnalité fait sur l’autre, sans qu’aucune des parties ne les écrive nulle part. Un environnement de mise en scène est un bien meilleur endroit pour découvrir cela qu’une autopsie.

Où les tests en boîte noire s’intègrent dans les pipelines d’intégration continue

Au niveau de la surveillance, les tests exploratoires en boîte noire ne s’arrêtent jamais vraiment. Dans les environnements de production ou proches de la production, les testeurs continuent d’explorer. Pas contre une liste de contrôle mais contre la curiosité. Qu’est-ce que cela fait lorsque vous essayez quelque chose que personne n’a spécifié ? C’est là que se trouvent les choses étranges – les échecs qui ne correspondaient à aucun scénario prévu et qui seraient restés invisibles jusqu’à ce qu’un utilisateur tombe dessus.

Avant la sortie d’une version, les parcours utilisateur les plus à risque reçoivent un laissez-passer supplémentaire de l’extérieur. Pas tout – cela prendrait trop de temps et passerait à côté de l’essentiel. Juste les flux où un échec ferait le plus mal. Les équipes qui se déploient quotidiennement ont appris à être impitoyables sur cette portée, car une couverture exhaustive au rythme des sorties n’est pas un objectif réaliste.

Tests de boîte noire dans les architectures de microservices

Le changement des microservices a compliqué tout cela d’une manière qui mérite d’être précisée.

Lorsque tout vivait dans une seule base de code, tester le système en boîte noire signifiait tester une chose en boîte noire. Vous avez appelé l’interface, regardé ce qui revenait, l’avez comparé à ce qui était censé revenir. Direct.

Divisez ce même système en quinze services et le problème devient tridimensionnel. L’utilisateur voit une chose. Derrière, les services communiquent entre eux via des API que l’utilisateur ne touche jamais. Quelque chose se brise au service neuf. Ce que l’utilisateur voit à la fin de cette chaîne ne ressemble en rien à ce qui s’est réellement cassé. Trois heures plus tard, quelqu’un découvre la véritable cause enfouie sous quatre services. Ce n’est pas le temps que quiconque consacre au sprint.

Les tests de boîte noire au niveau du système détectent toujours le symptôme rencontré par l’utilisateur. Mais détecter la cause profonde nécessite également des tests en boîte noire au niveau du service, ce qui signifie exercer les API entre les services de l’extérieur, sans savoir comment l’un ou l’autre service a été construit. Il s’agit d’une pratique différente des tests en boîte noire destinés aux utilisateurs, et elle nécessite que sa propre infrastructure soit réalisée de manière fiable.

Cela signifie que les tests modernes en boîte noire doivent fonctionner simultanément à plusieurs niveaux. Les tests de boîte noire au niveau du système valident ce que l’utilisateur voit. Les tests boîte noire au niveau du service valident le comportement des services individuels lorsqu’ils sont appelés via leurs API plutôt que leur code interne. Les tests boîte noire au niveau de l’intégration valident la manière dont les services communiquent entre eux depuis l’extérieur, sans connaître la manière dont l’un ou l’autre des services est implémenté.

Les tests en boîte noire au niveau des services et de l’intégration dans les environnements de microservices ont une exigence de précision spécifique qui devient de plus en plus importante à mesure que les services sont déployés plus fréquemment. L’environnement de test utilisé pour les tests en boîte noire doit représenter le comportement actuel des services, et non celui lors de la dernière configuration de l’environnement de test.

Dans une architecture de microservices où n’importe quel service peut déployer et modifier son comportement de manière indépendante, les environnements de test construits sur des représentations statiques du comportement des services deviennent inexacts à mesure que ces services se déploient. Maintenir les environnements de test en boîte noire à jour avec le comportement réel des services est l’un des défis pratiques que les flux de travail modernes ont ajoutés à la pratique traditionnelle des tests en boîte noire.

Le rôle des tests de boîte noire lorsque l’IA écrit du code

Les outils de codage de l’IA ont ajouté une couche que personne n’avait vraiment anticipée lorsque les outils ont commencé à se généraliser.

Un développeur qui a travaillé sur un système pendant deux ans possède de nombreuses connaissances qui n’ont jamais été intégrées dans une documentation. Le cas étrange de l’incident d’il y a dix-huit mois. Règle non écrite selon laquelle ce champ est toujours rempli en raison de quelque chose que fait le service en amont.

Un comportement à moitié fini, volontairement laissé vague car la décision sur le produit était toujours en attente. Rien de tout cela n’a été consigné dans la documentation. Il vit chez quiconque existe depuis assez longtemps pour se rappeler comment il en est arrivé là.

Les assistants de codage IA n’ont rien de tout cela. Ils ont l’invite et tout ce qu’ils ont appris pendant la formation. Ils produisent du code qui gère les scénarios décrits dans l’invite. Arrêt complet. Le contexte historique, les conventions d’équipe, les hypothèses non documentées – rien de tout cela n’est là à moins que quelqu’un ne le mette dans l’invite, ce que personne ne fait complètement, car la moitié existe sous forme de connaissance tacite que le développeur lui-même ne peut pas exprimer pleinement.

Cela rend les tests de boîte noire plus importants pour le code généré par l’IA, pas moins. Parce que la personne qui examine le code généré par l’IA ne peut pas se fier aux signaux normaux qu’elle utilise pour juger si les connaissances de mise en œuvre se sont traduites correctement en comportement correct. Le code semble raisonnable.

La question est de savoir s’il gère les choses que l’invite n’a pas mentionnées. Un testeur de boîte noire ne se soucie pas de ce que dit l’invite. Ils se soucient de savoir si la fonctionnalité fonctionne. Cet écart entre ce que l’invite décrit et ce que la fonctionnalité doit réellement gérer est exactement l’écart que les tests de boîte noire comblent.

À mesure que la génération de code IA devient plus répandue dans les flux de travail de développement, le rôle des tests en boîte noire en tant que couche de validation qui ne dépend pas des connaissances de celui qui a écrit le code devient plus que moins important.

Faire des tests de boîte noire une pratique cohérente

Les équipes qui tirent le meilleur parti des tests en boîte noire dans les flux de travail modernes ne sont pas celles qui en tirent le meilleur parti. Ce sont eux qui le font systématiquement aux bons moments du processus de livraison.

La cohérence signifie que les tests en boîte noire se déroulent à des étapes définies plutôt que uniquement lorsque le temps le permet. Cela signifie que chaque fonctionnalité importante est exercée en externe avant d’être expédiée, et pas seulement les fonctionnalités qui semblent risquées. Cela signifie que les environnements de test utilisés pour les tests en boîte noire reflètent le comportement actuel du système plutôt que de devenir obsolètes à mesure que le système évolue.

L’obstacle pratique à la cohérence des flux de travail modernes est généralement de deux ordres. Soit l’équipe n’a pas de propriétaire clair pour les tests en boîte noire, cela se produit donc de manière informelle et incohérente. Ou encore, les environnements de test utilisés pour les tests en boîte noire sont difficiles à maintenir à jour, de sorte que les tests en boîte noire sont de plus en plus exécutés sur des environnements qui ne reflètent pas fidèlement la production.

Les deux obstacles peuvent être résolus. La propriété est une décision de processus. La devise de l’environnement est une décision d’infrastructure quant à savoir si les environnements de test sont maintenus manuellement ou mis à jour automatiquement à mesure que le système évolue. Les équipes qui surmontent ces deux obstacles constatent que les tests en boîte noire deviennent un élément fiable de leur processus de livraison plutôt qu’un supplément facultatif qui est évincé lorsque la pression de livraison augmente.

Lorsque les tests en boîte noire sont cohérents et que les environnements dans lesquels ils s’exécutent sont actuels, ils font ce qu’ils ont toujours fait : détecter les échecs qui semblent improbables de l’intérieur et inévitables de l’extérieur. Cette fonction n’a pas changé à mesure que les flux de travail de développement logiciel ont évolué. Les flux de travail qui l’entourent l’ont.