Quelles sont les étapes du test logiciel ?

Tapez « quelles sont les étapes du test logiciel » dans un moteur de recherche et vous obtiendrez deux réponses différentes. Un site énumère quatre niveaux, du test unitaire jusqu’à l’acceptation. Un autre présente un processus de cinq à sept étapes, allant de la planification à la clôture. Les deux ont raison, mais ils divergent parce qu’ils répondent à des questions différentes.

Cependant, si vous demandez à un testeur de votre propre équipe, vous obtiendrez une troisième réponse, sans aucun rapport, mais tout aussi juste. Cette troisième réponse n’apparaît jamais dans les résultats de recherche, et c’est pourquoi elle surprend. Elle n’a rien à voir avec le produit dans son ensemble, et tout à voir avec un seul bug. Chacun traverse une courte série d’états. Quelqu’un confirme qu’il est réel, un développeur le corrige, et un testeur vérifie le résultat. C’est cette série que les gens désignent lorsqu’ils disent qu’un bug est passé à l’étape suivante.

Ce guide distingue les trois, afin que vous puissiez les différencier et déterminer celui dont vous avez besoin. La plupart des entreprises sont dotées en personnel pour un ou deux d’entre eux, et c’est pourquoi le troisième a tendance à passer à la trappe. Une équipe QA dédiée les couvre tous.

Quelles sont les étapes du test logiciel ? Trois choses que les gens entendent par là

La confusion est bien réelle, car une seule expression recouvre trois idées distinctes, et une source qui en explique une mentionne rarement les autres.

Regardez la colonne du milieu : les niveaux concernent la portée, le cycle de vie concerne le processus, et le cycle de vie d’un bug suit un seul défaut, du signalement à la clôture. Un après-midi donné, votre équipe peut se trouver au niveau système, à mi-parcours du cycle de vie, et gérer quarante défauts dans quatre états différents. Aucun de ces faits n’en contredit un autre.

Le nombre d’étapes dépend de la personne à qui vous le demandez, et quiconque promet une réponse unique et correcte simplifie. La variation n’est pas aléatoire :

• Les niveaux sont fixés à quatre. Personne ne défend sérieusement un autre décompte.
• Le cycle de vie n’est pas fixé. Certains auteurs séparent la planification de l’analyse et d’autres les combinent, d’où proviennent le cinq, le six et le sept.
• Les états d’un bug suivent la convention, pas une norme. Sept d’entre eux sont quasi universels, et c’est votre outil de suivi qui décide s’il y en a davantage.

Les quatre niveaux de test et ce que chacun attrape

Les niveaux répondent à la question de la portée : quelle part du produit vous testez à la fois. Ils vont du plus petit élément jusqu’au produit fini utilisé par une vraie personne.

• Test unitaire : une seule fonction, méthode ou classe, vérifiée isolément, avec tout ce qui l’entoure simulé. Les développeurs les écrivent en même temps que le code, et ils s’exécutent en quelques secondes.
• Test d’intégration : deux éléments ou plus vérifiés ensemble, ce qui vous indique s’ils s’accordent sur les données qui transitent entre eux. C’est ici qu’une connexion qui fonctionne et une page de profil qui fonctionne se révèlent en désaccord sur la forme d’un identifiant utilisateur.
• Test système : le produit assemblé dans son entier, vérifié de bout en bout au regard de ce qu’il était censé faire. Des testeurs indépendants l’exécutent, car à ce stade vous voulez quelqu’un qui ne l’a pas construit.
• Test d’acceptation : les personnes qui ont demandé le produit décident si elles ont obtenu ce qu’elles voulaient. C’est la dernière barrière avant la sortie, et il répond à une question qu’aucun niveau antérieur ne pose. Les tests alpha et bêta se situent tous deux ici, de même que la validation formelle.

Lisez cette dernière colonne de haut en bas et vous avez l’argument en faveur de l’exécution des quatre. Chaque niveau est aveugle à quelque chose que le suivant attrape, et le prix d’une correction grimpe à chaque étape. Une erreur de nommage attrapée par un test unitaire coûte deux minutes à un développeur. La même erreur découverte lors de l’acceptation coûte une sortie.

Rien de tout cela ne change sur mobile. Les quatre niveaux s’y appliquent aussi, et savoir à quelle étape de test d’application vous vous trouvez vous indique qui devrait exécuter les vérifications et à quel point un oubli devient coûteux.

Exemple : la réinitialisation de mot de passe à travers les quatre niveaux de test

Prenons par exemple une réinitialisation de mot de passe, puisque presque tout produit en possède une et que tout le monde en a déjà utilisé une dans la vraie vie.

Le test unitaire examine séparément les petits éléments. Le générateur de jetons produit-il quelque chose que personne ne peut deviner ? Le calcul d’expiration renvoie-t-il le bon horodatage ? Un développeur les écrit en construisant la fonctionnalité, et ils s’achèvent en quelques millisecondes.

Le test d’intégration se demande si ces éléments s’accordent entre eux. La requête doit atteindre le service de messagerie, le jeton doit survivre à l’aller-retour, et la base de données doit enregistrer qu’une réinitialisation est en attente. La plupart des bugs de réinitialisation de mot de passe se logent à ces points de passage, car chaque élément fonctionne parfaitement bien tout seul.

Le test système suit tout le parcours comme le ferait une personne. Demander une réinitialisation, ouvrir le courriel, cliquer sur le lien, choisir un nouveau mot de passe, se connecter. Un testeur emprunte aussi les chemins que personne n’a prévus : cliquer deux fois sur le lien, le laisser expirer, demander trois réinitialisations d’affilée.

Le test d’acceptation se demande tout autre chose. Cela correspond-il à ce que l’entreprise a convenu ? Si votre équipe de sécurité a dit que les liens de réinitialisation expirent au bout d’une heure et que le build sort avec 24, les trois niveaux antérieurs réussissent et la fonctionnalité est malgré tout erronée.

L’acceptation est le seul niveau qui l’attrape, et c’est pourquoi les quatre méritent leur place. Trois peuvent repasser au vert alors que le produit échoue encore au seul test qui reflète ce que quelqu’un a réellement demandé.

Pourquoi la régression, la performance et la sécurité sont des types, pas des étapes

Voici la distinction qui évite le plus de confusion une fois qu’on la tient. Une étape est quelque chose que l’on traverse dans l’ordre, tandis qu’un type est un travail que l’on peut effectuer à plusieurs d’entre elles. Les éléments suivants sont des types de test :

• Le test de régression n’est lié à aucun niveau en particulier, puisque son rôle est de confirmer que ce qui fonctionnait la semaine dernière fonctionne encore aujourd’hui. Exécutez-le sur tout ce qu’un changement pourrait atteindre, pas seulement sur la partie modifiée.
• Le test de performance peut cibler un seul service isolément ou l’ensemble du système sous charge réelle. Placez-le partout où une réponse lente vous coûterait véritablement quelque chose.
• Le test de sécurité peut examiner les permissions d’un seul point de terminaison ou le produit fini à la manière d’un attaquant. Traitez-le comme continu, car un seul changement d’accès peut ouvrir une brèche qu’aucun test fonctionnel ne repère.

Ainsi, lorsque quelqu’un demande à quelle étape appartient le test de performance, la réponse honnête est que la question ne tient pas tout à fait. Il appartient au niveau qui vous préoccupe. C’est pourquoi un plan de test utile nomme à la fois le niveau et le type.

Cycle de vie du test logiciel : bref aperçu

L’autre réponse courante à la question des étapes du test logiciel est un processus, et non un ensemble de niveaux. Ce processus est le cycle de vie du test logiciel, généralement abrégé en STLC (Software Testing Life Cycle). Il décrit la façon dont un effort de test est organisé plutôt que ce qui est testé : examiner les exigences, planifier, construire les cas de test, préparer un environnement, exécuter les tests, puis conclure par un rapport.

Cette séquence mérite plus de place que cet article ne peut lui en accorder, et nous avons un guide détaillé dédié. Notre guide du cycle de vie du test logiciel couvre chaque phase ainsi que ses critères d’entrée et de sortie.

Une précision a sa place ici, car elle suscite de vraies disputes. Cette première phase suppose de disposer d’exigences à partir desquelles un testeur peut travailler, ce qui est un problème distinct ayant sa propre réponse dans notre guide des exigences du test logiciel. Le cycle de vie vous dit quand les exigences sont examinées. Il ne vous dit pas à quoi ressemble une bonne exigence.

Le cycle de vie d’un bug : de Nouveau à Clôturé en sept états

Le test trouve des bugs, quel que soit le niveau ou le type auquel il se produit, et chacun d’eux suit ensuite une séquence qui lui est propre. C’est la troisième chose que l’on appelle étapes, et c’est celle que vos développeurs entendent le plus probablement.

1. Nouveau, signalé par le rapporteur : le bug est consigné, et personne n’a encore confirmé qu’il est réel.
2. Assigné à un responsable : le tri l’a accepté et l’a confié à une personne nommée.
3. En cours chez un développeur : quelqu’un travaille sur le correctif.
4. Corrigé du point de vue du développeur : une affirmation plutôt qu’une conclusion.
5. Revérifié par un testeur : quelqu’un confronte cette affirmation aux étapes de reproduction d’origine.
6. Validé par la revérification : le problème a bel et bien disparu.
7. Clôturé et consigné : le travail est terminé.

Deux autres états se situent en dehors de ces sept. Réouvert signifie qu’un correctif validé s’est de nouveau cassé, ce qui pointe généralement vers un test de régression manquant plutôt que vers un développeur négligent. Reporté signifie que l’équipe a convenu que le bug est réel et a choisi de ne pas le corriger pour l’instant, ce qui est une décision légitime tant que quelqu’un a consigné pourquoi.

L’endroit où un bug a été trouvé ne change rien aux états qu’il traverse. Un bug attrapé par un test unitaire et un bug attrapé lors de l’acceptation suivent les mêmes sept. Ce qui change, c’est le coût de chaque étape au moment où vous y arrivez.

Comment QAwerk mène ces étapes en pratique

Nous ne traitons pas le test comme une phase unique proche de la fin. Nos ingénieurs rejoignent le projet à l’étape où il en est et travaillent à l’intérieur du sprint, si bien que les quatre niveaux s’exécutent en continu au lieu de s’accumuler avant une sortie. Pour le détail au fil des semaines, voyez notre guide du test agile.

En pratique, cela signifie que nous prenons un produit là où il en est. Certaines équipes nous font intervenir avant qu’une seule ligne de code n’existe, alors que les exigences sont encore en discussion. D’autres nous confient un build terminé et une date de lancement. Les deux fonctionnent, même si le premier coûte moins cher, pour la même raison qu’un test unitaire coûte moins cher qu’un échec à l’acceptation.

La qualité dépend de qui la réalise. Nous comptons plus de 30 ingénieurs QA seniors totalisant en moyenne 9 ans d’expérience chacun, et nous avons identifié plus de 50 000 bugs critiques sur plus de 300 projets depuis 2015. Cette expérience compte le plus aux points précis où les niveaux deviennent aveugles : savoir quelle intégration risque d’être en désaccord, et quel scénario d’acceptation personne n’a pensé à écrire.

Pour découvrir où se situe réellement votre produit au regard des quatre niveaux, parlez à notre équipe QA. Nous cartographierons votre couverture actuelle avant que vous ne vous engagiez à quoi que ce soit.

FAQ