01 — Cycle de vie
Les modèles de cycle de vie
Le test ne se place pas au même endroit selon la façon dont le projet est organisé. Cliquez sur une carte pour voir quand utiliser chaque modèle, comment il fonctionne, et un exemple.
Cascade (Waterfall)
Quand : Des exigences stables et connues dès le départ, dans un contexte où un changement en cours de route coûte cher : réglementation, contrat figé, matériel déjà en fabrication.
Comment : Chaque phase se termine avant que la suivante commence : recueil des exigences, conception, développement, test, puis mise en production. Le test n'arrive qu'à la toute fin du projet.
Exemple : Le logiciel embarqué d'un équipement médical, dont le cahier des charges est validé en amont et où revenir en arrière coûte très cher une fois la fabrication lancée.
Cycle en V
Quand : On veut garder une structure séquentielle proche de la cascade, mais en préparant le test dès la phase de conception correspondante plutôt qu'à la toute fin.
Comment : Chaque phase de conception a sa phase de test miroir, ce qui permet de préparer les cas de test bien avant leur exécution, en même temps que le reste du projet avance.
Exemple : Les exigences fonctionnelles rédigées en tout début de projet servent aussi à préparer les tests d'acceptation, qui ne seront exécutés que des mois plus tard.
Itératif
Quand : Les exigences ne sont pas toutes connues au départ, ou le produit doit évoluer au fil des retours des utilisateur•rices.
Comment : Le produit se construit par cycles successifs, chacun affinant ou complétant les précédents. Une décision prise tôt peut être révisée à l'itération suivante.
Exemple : Un prototype de logiciel métier affiné après chaque démonstration aux utilisateur•rices, en intégrant leurs retours au cycle suivant.
À la différence de l'incrémental : on retravaille le même périmètre, encore et encore, pour l'affiner. On ne l'agrandit pas forcément à chaque cycle.
Incrémental
Quand : Le produit final est trop volumineux pour être livré d'un coup, mais chaque partie apporte déjà de la valeur toute seule.
Comment : Le produit est découpé en morceaux fonctionnels livrés progressivement, chacun testé et intégré aux précédents.
Exemple : Une plateforme e-commerce livrée d'abord avec la recherche de produits, puis le panier, puis le paiement, chaque brique testée avant sa mise en production.
À la différence de l'itératif : chaque livraison ajoute un morceau nouveau et définitif au produit, plutôt que de retravailler un morceau déjà livré.
02 — Agilité et DevOps
Le test à chaque sprint, pas à la fin
Hors syllabus FondationL'agilité renverse la logique du cycle en V : au lieu de tout spécifier avant de coder, l'équipe construit le produit par sprints courts, généralement de deux ou trois semaines, en intégrant le test à chaque étape plutôt qu'à la toute fin. Le DevOpsContraction de « Development » et « Operations » : une culture qui rapproche développement et exploitation pour livrer plus vite et plus souvent, en gardant la qualité à chaque étape. prolonge cette logique jusqu'à la mise en production et au-delà.
Sprint planning
Début
L'équipe choisit les user stories du sprint à venir et discute des critères d'acceptation, avant même que le développement ne commence.
Daily
Pendant
Le point quotidien permet à chacun de signaler tôt ce qui le bloque : un blocage de développement, un blocage de test, un environnement instable ou une anomalie qui retarde la validation d'une story.
Sprint review
Fin
Les fonctionnalités terminées sont démontrées au•à la client•e ou au Product Owner, notamment sous forme de recette utilisateur. Le•la testeur•se peut y présenter les résultats de test et les risques restants.
Rétrospective
Fin
L'équipe revient ensemble sur ce qui a bien ou mal fonctionné pendant le sprint : organisation, collaboration, outils, qualité — tests qui ont manqué, anomalies découvertes tardivement.
Avantages :
Approche toute l'équipe
La qualité n'appartient plus seulement au•à la testeur•se. Développeur•ses, Product Owner et testeur•ses la partagent tout au long du sprint, plutôt que de la reporter sur une seule personne à la fin.
Intégration continue
Une chaîne automatisée exécute les tests à chaque commit. Un défaut est détecté en quelques minutes plutôt qu'en quelques semaines.
Déploiement continu
Selon le projetLe logiciel validé est mis en production automatiquement, souvent plusieurs fois par jour. Le test se prolonge après la mise en ligne, avec du monitoring et des vérifications ciblées.
03 — Shift-left et shift-right
Étendre le test avant et après le développement
Ces deux notions décrivent le même mouvement, dans deux directions opposées : sortir le test de sa place traditionnelle, entre le développement et la mise en production.
Shift-left
Déplacer le test vers l'amont du projet, avant même que le code existe : revue des exigences, tests unitaires écrits en même temps que le code, critères d'acceptation définis avant le développement. L'objectif est de détecter un défaut au moment où il coûte le moins cher à corriger.
Shift-right
Prolonger le test vers l'aval, une fois le logiciel en production : monitoring, tests A/BComparer deux versions d'une fonctionnalité auprès d'utilisateurs réels, pour mesurer laquelle fonctionne le mieux avant de généraliser., feature flagsInterrupteurs qui activent ou désactivent une fonctionnalité en production sans redéployer le code, utiles pour tester progressivement ou revenir en arrière rapidement., tests de résilience. L'objectif est de vérifier le comportement réel du logiciel, dans des conditions qu'un environnement de test ne reproduit pas toujours fidèlement.
04 — Approches pilotées par les tests
TDD, BDD, ATDD
Trois pratiques différentes, mais un point commun : le test ou le critère d'acceptation s'écrit avant le code, pas après.
TDD (Test-Driven Development)
- Rouge : il•elle écrit un test qui échoue avant d'écrire le code.
- Vert : il•elle écrit le code minimal nécessaire pour le faire passer.
- Refactor : il•elle nettoie le code sans changer son comportement, en s'appuyant sur le test pour vérifier qu'il ne casse rien.
Exemple : Avant de coder une fonction de remise, le•la développeur•se écrit d'abord un test qui vérifie qu'un panier de 120 euros avec un code promo de 10 % donne 108 euros (rouge), il•elle code la fonction jusqu'à ce que ce test passe (vert), puis il•elle nettoie l'implémentation (refactor).
BDD (Behavior-Driven Development)
Exemple : « Étant donné que le panier contient 120 euros, quand le•la client•e applique un code promo de 10 %, alors le total affiché est de 108 euros. »
ATDD (Acceptance Test-Driven Development)
Exemple : Avant de développer le code promo, testeur•se, développeur•se et Product Owner s'accordent ensemble sur les cas à couvrir : code valide, expiré, déjà utilisé, cumul interdit.
05 — Les 3C
Construire une user story à plusieurs
Les 3C décrivent comment une user story agile prend forme, de son écriture initiale jusqu'à la confirmation qu'elle est terminée.
Carte
Une user story se résume sur une carte, en une ou deux phrases. Elle ne décrit pas tout, elle sert surtout de point de départ à la discussion.
Conversation
Les détails de la story se construisent par la discussion entre l'équipe et le métier, plutôt que d'être figés dans un document écrit à l'avance.
Confirmation
Des critères d'acceptation, souvent au format « Étant donné que, quand, alors », confirment ce que « terminé » veut dire pour cette story précise.
06 — Le•la testeur•se dans l'agilité
Le•la testeur•se, du sprint planning à la review
Le•la testeur•se agile n'attend plus la fin du sprint pour entrer en scène. Il·elle est présent·e du premier jour au dernier.
Definition of Done
Une liste de critères communs à toutes les stories d'un sprint (code relu, tests unitaires passés, tests d'acceptation validés, documentation à jour) qui doit être remplie avant de considérer une story terminée.
Le•la testeur•se dans le sprint
Il•elle participe à la conception des critères d'acceptation dès le sprint planning, teste au fur et à mesure que les fonctionnalités avancent plutôt qu'à la toute fin, et automatise ce qui peut l'être pour garder du temps pour l'exploratoire.
A retenir
Ce qu'il faut retenir
Le V prépare, le sprint intègre
Le cycle en V prépare le test dès la conception alors que l'agilité l'intègre en continu, à chaque sprint.
Avant et après le développement
Le shift-left rapproche le test du début du projet, le shift-right le prolonge après la mise en production.
Le test avant le code
TDDTest-Driven Development, BDDBehavior-Driven Development et ATDDAcceptance Test-Driven Development partagent une même idée. On écrit le test ou le critère d'acceptation avant le code, pas après.
De la carte à la confirmation
Les 3C structurent la construction d'une user story, de la carte résumée à la confirmation par les critères d'acceptation.
Une responsabilité partagée
En agilité, la qualité n'est plus la responsabilité d'une seule personne, elle est partagée par toute l'équipe.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Dans quel modèle de cycle de vie chaque phase de conception a-t-elle sa phase de test miroir ?
Un•e développeur•se écrit un test qui échoue avant d'écrire le code, puis code jusqu'à ce que le test passe. Quelle pratique est-ce ?
"Étant donné que le panier contient 120 euros, quand le•la client•e applique un code promo de 10 %, alors le total affiché est de 108 euros." Quel format est utilisé ici ?
Une équipe détecte un défaut en quelques minutes grâce à des tests exécutés automatiquement à chaque commit. De quelle pratique s'agit-il ?
Rapprocher le test du début du projet, avant même que le code existe, en révisant les exigences et en écrivant des tests unitaires tôt : c'est...
Dans les 3C, à quoi correspond la Confirmation ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin