Test boîte noire en génie logiciel

Le test boîte noire en génie logiciel examine un produit depuis l’extérieur, sans aucune vue sur le code source, exactement comme vos clients l’utilisent. Cette limite est délibérée, car ceux qui paient pour le produit ne voient pas non plus l’intérieur. Ils trouvent pourtant les parties défaillantes dans les jours qui suivent un lancement.

Il existe aussi une raison commerciale de s’y intéresser. Des testeurs qui ne reçoivent jamais votre code ne peuvent pas le divulguer, et c’est pourquoi de nombreuses entreprises confient les tests manuels à un partenaire externe plutôt que d’ouvrir leurs systèmes.

Dans ce guide, nous vous présentons en détail le test boîte noire et ses quatre techniques principales. Nous verrons également quand utiliser le test boîte noire ou le test boîte blanche dans des projets réels.

Ce qu'est réellement le test boîte noire en génie logiciel

Le nom est emprunté à l’ingénierie, où une boîte noire désigne tout système jugé uniquement sur ce qui y entre et ce qui en sort. Les testeurs procèdent de la même façon. Certains n’ont pas accès au code, les autres choisissent de ne pas le regarder.

La profession a un second terme pour cela, le test basé sur les spécifications, et celui-ci décrit le travail plus honnêtement. L’ISTQB, l’organisme qui maintient la terminologie standard des testeurs dans le monde entier, le définit comme une approche de test fondée sur la spécification d’un composant ou d’un système. En clair, quelqu’un écrit ce que le produit est censé faire, et un testeur vérifie qu’il le fait exactement.

Un testeur n’a pas besoin de savoir comment le logiciel a été construit. Il travaille à partir des exigences, des descriptions de fonctionnalités et des écrans qu’il a devant lui, puis compare ce qui se produit à ce qui avait été promis.

Le test boîte blanche part au contraire de l’extrémité opposée. L’ingénieur lit le code source et cartographie chaque décision qu’il prend, comme diriger les clients payants d’un côté et les utilisateurs gratuits de l’autre. Chacun de ces choix reçoit ensuite son propre test, de sorte que rien à l’intérieur ne reste non vérifié.

Aucune des deux approches ne l’emporte totalement, car elles répondent à des questions différentes. L’une vous dit si le produit remplit sa fonction. L’autre montre si le code sous-jacent est solide. La plupart des équipes saines pratiquent les deux, à des moments différents et généralement avec des personnes distinctes.

Les quatre techniques fondamentales du test boîte noire

Vous ne pouvez pas tout tester. Par exemple, un formulaire de réservation avec seulement cinq questions, chacune acceptant dix réponses différentes, produit déjà 100 000 combinaisons. Comme personne n’a le temps de les parcourir une à une, les spécialistes utilisent quatre techniques de test boîte noire qui réduisent la liste aux vérifications les plus susceptibles de révéler de vrais bogues.

Partitionnement en classes d'équivalence : tester une valeur par groupe

Un logiciel traite rarement chaque entrée comme unique. Il les classe en groupes et applique la même règle à chacun.

Imaginez un formulaire d’inscription qui accepte les candidats de 18 à 65 ans. Tous ceux qui se situent dans cette plage sont traités de façon identique, donc essayer 34 puis 47 ne vous apprend rien de neuf. Trois résultats existent réellement ici : trop jeune, accepté et trop âgé. Le partitionnement en classes d’équivalence consiste à choisir une valeur dans chaque groupe et à lui faire confiance pour représenter les autres.

Ces 48 âges acceptés ne réclament qu’un seul test à eux tous, tandis que les deux groupes rejetés en demandent un chacun. Cette technique couvre aussi les entrées censées échouer, comme des lettres saisies dans un champ numérique ou une case laissée vide, et les sonder délibérément s’appelle le test négatif.

Analyse des valeurs limites : tester les bords de chaque groupe

Les bogues s’accumulent aux bords de chaque groupe, c’est-à-dire aux points précis où la réponse bascule d’accepté à rejeté. Le formulaire d’inscription de notre exemple en compte deux : le passage de 17 à 18 ans et celui de 65 à 66 ans.

Voilà où cela dérape. La règle dit que les candidats doivent avoir 18 ans ou plus, mais la personne qui construit le formulaire écrit « plus de 18 ans » à la place. Ces deux formulations semblent identiques jusqu’à ce qu’un jeune de 18 ans tente de s’inscrire et se voie refuser l’accès.

Vous testez donc les valeurs de part et d’autre de chaque bord : 17 et 18 en bas, 65 et 66 en haut. Cela fait quatre vérifications, et elles attrapent une erreur qui se glisse constamment dans les logiciels. Notre guide sur l’analyse des valeurs limites va plus loin et montre comment la même idée s’applique aux dates, aux tailles de fichiers et au nombre d’enregistrements qu’un système accepte d’un coup.

Test par table de décision : cartographier chaque combinaison de règles

Certains comportements dépendent de plusieurs conditions à la fois, et c’est là que les équipes perdent le fil. Une table de décision énumère chacune d’elles, puis précise ce qui doit se produire pour chaque combinaison.

Supposons que votre tunnel de commande offre la livraison gratuite au-delà de 50 dollars, et que les membres du programme de fidélité gagnent des points sur tout ce qu’ils achètent. Deux conditions produisent quatre résultats :

Écrites ainsi, les lacunes sautent aux yeux. Les équipes vérifient couramment la première ligne et la dernière, puis livrent sans avoir essayé les deux du milieu. C’est exactement là qu’un membre qui dépense 40 dollars paie les bons frais et ne reçoit jamais ses points.

Ajoutez une troisième condition, comme un code de réduction, et la table double pour atteindre huit lignes. Cette croissance est tout l’intérêt, car chaque nouvelle ligne est une combinaison que vos clients finiront par rencontrer, que quelqu’un l’ait essayée avant ou non.

Test de transition d'états : suivre le parcours de l'utilisateur

Certaines fonctionnalités se comportent différemment selon ce qui s’est passé avant, et c’est cet historique que cette technique examine. Le logiciel se trouve dans un état, un événement le fait passer à un autre, et le testeur suit le parcours.

Le verrouillage de compte en est l’exemple le plus clair. Au départ, tout le monde est en règle. Puis un mot de passe erroné ajoute un avertissement, un deuxième en ajoute un autre, et un troisième bloque la connexion pendant 15 minutes. Cependant, réussir à un moment quelconque devrait effacer ce compteur et laisser entrer la personne.

Parcourir ce chemin fait apparaître les vérifications qui valent la peine :

• Le compteur d’échecs devrait se réinitialiser complètement, sans rien laisser de mardi qui se combine avec deux autres le vendredi.
• Le verrouillage devrait se lever de lui-même au bout de 15 minutes au lieu de tenir jusqu’à l’intervention du support.
• Un compte verrouillé devrait refuser de nouvelles tentatives pendant qu’il attend.

Aucune de ces vérifications n’exige l’accès au code source. Elles réclament seulement quelqu’un qui accepte de suivre la séquence entière plutôt que de tester chaque écran isolément.

Où le test boîte noire s'inscrit dans votre processus de développement

Le travail en boîte noire peut commencer dès que des exigences écrites existent, soit plus tôt que la plupart des équipes ne l’imaginent. Les testeurs conçoivent les cas à partir de la spécification elle-même, donc la préparation démarre pendant que les développeurs construisent encore.

Il devient la méthode principale à deux étapes ultérieures :

• Les tests système examinent le produit assemblé au regard de ce qui avait été spécifié, en couvrant l’ensemble plutôt que ses parties.
• Les tests d’acceptation demandent aux personnes qui ont commandé le logiciel s’il résout leur problème. Ces relecteurs n’ont jamais vu le code, et ils n’en ont pas besoin. C’est le test boîte noire dans sa forme la plus pure.

Les tests alpha et bêta appartiennent à la même famille. Tous deux confient une version à de vrais utilisateurs et observent ce qui casse, un groupe à l’intérieur de l’entreprise et un à l’extérieur. Notre comparaison des tests alpha et bêta détaille en quoi ils diffèrent en pratique.

Cependant, cette méthode ne peut pas prouver que chaque ligne de votre code a été exécutée. Une fonctionnalité peut réussir toutes ses vérifications extérieures alors qu’une branche entière de la logique reste intacte derrière, en attente d’une entrée inhabituelle. Les développeurs comblent cet écart avec des tests unitaires, de petits programmes écrits pour inspecter directement le code. Les tests automatisés rejouent ensuite les scénarios visibles par l’utilisateur à chaque build, de sorte que vous apprenez immédiatement si quelque chose qui fonctionnait ne fonctionne plus. Ces efforts se complètent au lieu de se concurrencer.

Pourquoi le test boîte noire compte quand vous externalisez la QA

Confier votre code source à une entreprise extérieure est une décision au poids juridique réel. Les contrats s’allongent, les revues de sécurité entrent en jeu, et certaines organisations refusent tout simplement.

Le test boîte noire évite entièrement cette décision. Un partenaire qui applique ces techniques n’a besoin que de vos exigences, d’une version fonctionnelle et de quelques comptes pour se connecter. Comme votre code ne quitte jamais votre entreprise, vos juristes ont beaucoup moins à vérifier. Les tests peuvent démarrer en quelques jours au lieu d’attendre une validation.

Cela signifie aussi qu’un partenaire externe peut rejoindre un projet à n’importe quelle étape, sans version finalisée ni transfert de code. Une équipe d’assurance qualité dédiée peut commencer par la moitié du produit qui fonctionne déjà pendant que vos ingénieurs terminent le reste.

Voici ce que cela donne en pratique : Escuela Coaching, basée à Madrid, a demandé une revue indépendante de sa plateforme en ligne avant le lancement. Nos ingénieurs ont testé les portails coach et client sur 7 appareils en un mois environ et ont signalé plus de 100 défauts. Aujourd’hui, la plateforme sert plus de 300 organisations.

Le même raisonnement vaut pour la sécurité. Le test dynamique de sécurité applicative sonde un système en fonctionnement depuis l’extérieur, à la recherche de faiblesses, sans lire une seule ligne de code source. Cela place le test de sécurité des applications web dans la même famille et en fait une autre mission qu’un spécialiste externe peut mener sans votre code.

Le test boîte noire est un choix, pas un compromis

Travailler sans le code source ressemble à une lacune de la méthode jusqu’à ce que l’on voie ce que cela apporte. Les vérifications reflètent la manière dont de vrais clients utilisent le produit, et ceux qui les exécutent n’ont jamais besoin d’accéder à votre code. Ensemble, ces deux faits expliquent pourquoi une si grande part des tests est confiée à une équipe externe.

QAwerk applique ces techniques dans ses tests manuels, ses tests système et ses tests d’acceptation. Pour déterminer lesquels votre prochaine version réclame vraiment, parlez à nos ingénieurs QA.

Qu'est-ce que le test boîte noire en génie logiciel ?

Le test boîte noire en génie logiciel consiste à juger un produit sur ce qu’il fait, et non sur la façon dont il a été construit. Un testeur travaille à partir des exigences et des écrans, jamais du code source. On l’appelle aussi test basé sur les spécifications, l’approche standard pour les tests système, les tests d’acceptation et l’essentiel de la QA manuelle.

Quelles sont les principales techniques de test boîte noire ?

Quatre techniques couvrent la plupart des situations. Le partitionnement en classes d’équivalence répartit les entrées en groupes qui se comportent de la même manière, puis teste un membre de chacun. L’analyse des valeurs limites cible les valeurs situées précisément là où une règle commence ou cesse de s’appliquer. Le test par table de décision parcourt chaque combinaison de conditions. Le test de transition d’états vérifie comment une fonctionnalité réagit lorsque son statut change.

Le test boîte noire peut-il être automatisé ?

Oui, et la plupart des équipes automatisent les parties répétitives. Un script peut remplir un formulaire, le soumettre et confirmer la réponse sans que personne ne regarde, ce qui convient à tout ce que vous répétez à chaque build. Le travail exploratoire et le jugement sur la cohérence réelle d’un écran restent manuels. La plupart des produits finissent avec un mélange des deux.

Les testeurs boîte noire doivent-ils savoir coder ?

Non. Ces techniques reposent sur la compréhension du produit, de ses utilisateurs et des exigences écrites, pas sur la lecture du code. Beaucoup d’ingénieurs QA apprennent le scripting avec le temps, et cela élargit ce qu’ils peuvent prendre en charge. Concevoir des cas de test à partir d’une spécification ne demande toutefois aucune formation en développement.

Quand faut-il utiliser le test boîte noire ?

Tournez-vous vers lui chaque fois que la question est de savoir si le produit fonctionne pour ses utilisateurs. Il convient aux tests système et d’acceptation, aux versions livrées sous contrainte de délai et à tout arrangement dans lequel un prestataire ne devrait pas recevoir votre code source. Associez-le aux tests unitaires des développeurs, car aucune des deux approches ne raconte à elle seule toute l’histoire.