Lorsqu’un bug atteint la production, la cause n’est souvent pas que quelqu’un ait oublié d’exécuter un test. C’est qu’une exigence n’a jamais été remise en question, que les données de test étaient erronées ou que personne n’était d’accord sur ce que signifiait « fait ». Le cycle de vie des tests logiciels résout ces problèmes en donnant aux tests une structure claire depuis la première exigence jusqu’au rapport final.

Ce guide explique chaque phase, puis suit une fonctionnalité illustrative à travers chacune d’elles : une page de connexion qui verrouille un compte après cinq tentatives infructueuses. Les sources ne sont pas entièrement d’accord sur le nombre de phases. Vous verrez des modèles à sept ou huit, mais ils répartissent généralement le même travail différemment. Nous utilisons la version en six phases, largement enseignée.

Qu’est-ce que le STLC ?

Le STLC est une série définie d’activités de tests effectuées pour confirmer que le logiciel répond à ses exigences. Chaque phase a un objectif, des entrées et des sorties, de sorte que les tests soient planifiés et traçables plutôt qu’improvisés à la fin.

Les avantages sont pratiques. Les testeurs interviennent tôt, lorsque les défauts sont moins coûteux à corriger. L’effort est dirigé vers les risques les plus élevés. Et lorsqu’un manager demande « sommes-nous prêts à libérer ? », l’équipe peut répondre avec des preuves.

Les six phases STLC en un coup d’oeil

Les Critères d’entrée sont les conditions qui doivent être remplies avant le début d’une phase. Les Critères de sortie sont les conditions qui doivent être vraies avant la fin. Ils empêchent une équipe, par exemple, d’exécuter des tests sur une version cassée et de perdre une journée.

Phase 1 : Analyse des besoins

Les testeurs étudient les exigences pour découvrir ce qui peut être testé et ce qui n’est pas clair. C’est souvent l’endroit le moins cher pour prévenir un bug, puisqu’une question coûte bien moins cher qu’un correctif en production.

• Entrée : des documents d’exigences ou des user stories sont disponibles.
• Activités : identifier les besoins fonctionnels et non fonctionnels, poser des questions, évaluer les risques et décider de ce qui pourrait être automatisé.
• Quitter : les questions ouvertes reçoivent une réponse et la matrice de traçabilité des exigences (RTM) est lancée.
• Livrables : une liste d’exigences testables et le RTM.

Exemple de connexion. L’histoire dit “verrouiller le compte après cinq tentatives infructueuses”. Un bon testeur demande : cinq dans quelle période ? Comment est-il débloqué ? Une connexion réussie réinitialise-t-elle le décompte ? Quel message s’affiche ? Chaque réponse devient quelque chose de testable.

Phase 2 : Planification des tests

L’équipe décide de la portée, de l’approche, des personnes, des outils, du calendrier et des risques. Le responsable du test est généralement propriétaire de cette phase.

• Entrée : analyse des exigences et évaluation initiale des risques.
• Activités : définir la portée, estimer les efforts, sélectionner les outils, attribuer des rôles et définir des critères de sortie pour les phases ultérieures.
• Quitter : le plan de test est examiné et approuvé.
• Livrables : le plan de test et les estimations d’effort.

Exemple de connexion. Dans le périmètre : règles de verrouillage, réinitialisation et messages d’erreur sur web et mobile. Hors de portée : authentification unique, gérée par une autre équipe. Le plus grand risque est de bloquer les utilisateurs authentiques, c’est donc celui qui retient le plus l’attention. Si vous ne savez pas en quoi un plan diffère d’une stratégie, lisez plan de test vs stratégie de test.

Phase 3 : Développement de cas de test

C’est ici que les testeurs rédigent les cas de test détaillés, les scripts d’automatisation et les données de test.

• Entrée : un plan de test approuvé et des exigences stables.
• Activités : rédiger et réviser des cas de test, préparer les données, scripter les vérifications automatisées et mettre à jour le RTM.
• Quitter : les cas de test et les données sont examinés et prêts.
• Livrables : cas de test, scripts et données de test.

Notez que TC-01 et TC-02 testent chaque côté de la limite, ce qui vient directement de l’analyse des valeurs limites. Pour en savoir plus sur leur écriture, consultez comment rédiger des cas de test.

Phase 4 : configuration de l’environnement de test

Les tests doivent être exécutés dans un endroit réaliste : les bons serveurs, données, comptes, navigateurs et accès au réseau. Cette phase se déroule souvent en parallèle de la phase 3 et peut être gérée par des développeurs ou une équipe DevOps.

• Entrée : un plan de test, un aperçu de l’architecture et des exigences d’environnement.
• Activités : configurer le matériel ou les conteneurs, charger les données, configurer l’accès et installer la build.
• Sortie : l’environnement est prêt et un test de fumée réussit.
• Livrables : un environnement de travail et un résultat de test de fumée.

Exemple de connexion. La préparation obtient des comptes de test dans des états connus, ainsi qu’un délai de verrouillage raccourci afin que les testeurs n’aient pas à attendre. Un smoke test rapide confirme que la connexion se charge avant le début de l’exécution complète. Les conteneurs aident à maintenir la cohérence des environnements, comme le montre notre Tutoriel Docker Compose.

Phase 5 : exécution des tests

Les testeurs exécutent les tests planifiés, comparent les résultats réels et attendus et signalent les défauts. Les bogues corrigés sont retestés et les domaines associés subissent des tests de régression.

• Entrée : les cas de tests sont prêts, l’environnement fonctionne et un build a été livré.
• Activités : exécuter des tests, enregistrer les résultats, consigner les défauts, retester les correctifs et mettre à jour le RTM.
• Quitter : les tests planifiés sont exécutés et les défauts sont corrigés ou formellement acceptés.
• Livrables : résultats des tests et rapports de défauts.

Exemple de connexion. TC-04 échoue : avec deux navigateurs, le compteur n’atteint que quatre. Le testeur enregistre le bogue avec des étapes et des preuves claires, comme décrit dans comment rédiger un rapport de bogue. Une fois le problème corrigé, TC-04 est réexécuté et les vérifications de connexion associées passent par la liste de contrôle de régression.

Phase 6 : Clôture des tests

Cette phase est souvent sautée, ce qui est dommage, car c’est ainsi qu’une équipe s’améliore. L’équipe évalue le cycle, archive son travail et enregistre ce qu’elle a appris.

• Entrée : l’exécution est terminée et l’état du défaut est connu.
• Activités : vérifier les critères de sortie, analyser les tendances des défauts, archiver les actifs de test et organiser une rétrospective.
• Quitter : le rapport de clôture est signé.
• Livrables : le rapport de clôture et les enseignements tirés.

Exemple de connexion. Le rapport montre que les cinq cas ont été résolus après une seule correction. La leçon est que la concurrence n’a été testée que tardivement, de sorte que les futures fonctionnalités avec compteurs verront ce scénario ajouté lors de la conception.

STLC contre SDLC

Le SDLC, ou cycle de vie de développement logiciel, couvre la création de l’ensemble du produit. Le STLC est la partie axée sur les tests et fonctionne à ses côtés.

L’analyse des exigences dans le SDLC alimente l’analyse des exigences dans le STLC, et le développement intègre l’exécution des tests. Les tests ne doivent pas attendre la fin du codage. Commencer tôt, c’est ce que les gens entendent par « décaler vers la gauche ».

STLC en Agile et DevOps

Ces phases peuvent sembler être un long processus à sens unique, mais ce n’est pas obligatoire. En Agile, les mêmes activités se réduisent et se répètent au sein de chaque sprint, souvent en heures au lieu de semaines :

• L’analyse des besoins s’effectue lors du raffinement du backlog, à travers des questions sur la user story.
• La planification se produit dans la planification de sprint, avec des notes légères à la place de longs documents.
• La conception des tests s’effectue parallèlement au codage, souvent sous forme de critères d’acceptation et de tests automatisés.
• La configuration de l’environnement est automatisée via des conteneurs et une infrastructure sous forme de code.
• L’exécution s’exécute en continu dans un pipeline CI/CD.
• La Closure fait partie de la revue de sprint et de la rétrospective.

Conservez ce qui est utile et adaptez la paperasse au risque. Un petit outil interne peut nécessiter une courte liste de contrôle, tandis qu’un système bancaire peut avoir besoin d’approbations formelles pour des raisons réglementaires.

Erreurs courantes

• Amener les testeurs en retard. Les bugs trouvés dans les exigences sont bien moins chers que ceux trouvés après la publication.
• Critères de sortie vagues. Sans eux, les délais prennent la décision à votre place.
• Tests dans un environnement médiocre. Les échecs causés par des données ou une configuration incorrectes font perdre du temps et érodent la confiance.
• Sauter la clôture. L’équipe répète ensuite les mêmes erreurs lors du cycle suivant.
• Le suivre de manière trop rigide. Le STLC est un guide. Des documents lourds ne signifient pas automatiquement une meilleure qualité.

Pour conclure

Le cycle de vie des tests logiciels est simplement une réponse disciplinée à six questions : que testons-nous, comment, avec quels cas, où, que s’est-il passé et qu’avons-nous appris ? Examinez votre prochaine fonctionnalité et vérifiez lesquelles de ces questions votre équipe saute habituellement. Corriger cet écart vous apportera probablement le gain le plus important.

Questions fréquentes

Continuez à apprendre