Chapitre 2 : Cycle de Vie du Développement Logiciel

(SDLC) Préparé par Sahar Souahi - Analyste QA

📚 Introduction au SDLC
Un SDLC (Software Development Life Cycle) décrit quoi, qui, quand et comment produire
un logiciel de façon organisée.

Phases clés :

●​ Analyse des besoins​

●​ Conception​

●​ Développement (codage)​

●​ Tests​

●​ Déploiement​

●​ Maintenance​

🗂️ Catégories de modèles SDLC

ISTQB classe les modèles en deux familles :

-Modèles séquentiels (Waterfall, V-Model)​

-Modèles itératifs/agiles (Scrum, Kanban, Spiral, incrémental)

Astuce “shift-left” : impliquer les testeurs dès l’analyse pour détecter les
défauts le plus tôt possible.
🔄 Modèles séquentiels
Waterfall (Cascade)

Le modèle en cascade, connu sous le nom de Waterfall en anglais, est une

approche linéaire et séquentielle des différentes phases et activités d'un projet
nécessaires à la livraison du ou des livrables..
Cette méthode, souvent associée à la gestion de projet en cascade, implique une
progression étape par étape, où chaque phase de gestion de projet doit être
complétée avant de passer à la suivante :

1.​ Exigences : collecte et spécification​

2.​ Conception : architecture et maquettes​

3.​ Implémentation : codage selon les spécifications​

4.​ Tests : validation, correction des anomalies​

5.​ Déploiement : mise en production​

6.​ Maintenance : support et évolutions​

+ Avantages : simplicité, clarté​

- Inconvénients : rigidité, adaptations coûteuses, livraison tardive
V-Model ( Modéle V)
Le modèle V est une méthodologie de gestion de projet et de développement de
logiciels qui met l'accent sur une approche systématique et séquentielle, similaire au
modèle en cascade, mais avec une structure en forme de "V". Chaque phase de
développement est associée à une phase de test correspondante, formant ainsi une
forme en V.

Chaque phase de développement a son test associé :

●​ Spécifications ↔ Tests d’acceptation​

●​ Conception ↔ Tests système​

●​ Codage ↔ Tests unitaires​

+ Avantages : traçabilité, détection précoce​

- Inconvénients : coût et complexité, peu flexible

🚀 Modèles incrémental & itératif

Incrémental : livraisons partielles successives.

●​ Priorisation des fonctionnalités​

●​ Chaque incrément est conçu, testé et déployé indépendamment​

Itératif : cycles répétés d’amélioration.

●​ Prototype de toutes les fonctionnalités dès la première version​

●​ Enrichissement continu selon retours utilisateurs​

🔄 Méthode Agile (Scrum + PDCA)

Le développement logiciel agile est une approche de gestion de projets et de
développement de logiciels qui se concentre sur la flexibilité, la collaboration et la
livraison rapide de logiciels fonctionnels. Contrairement aux méthodes
traditionnelles, l'agilité permet de s'adapter aux changements et d'améliorer
continuellement le produit en fonction des retours des utilisateurs.

Le développement logiciel agile part du principe que des changements peuvent

intervenir tout au long du projet. Cette idée implique la décomposition du produit en
cycles qui se répètent tout au long du processus de développement. Ces cycles sont
appelés itérations. En résumé, chaque itération se compose de quatre étapes qui
forment la roue de Deming (PDCA):

1.​ Plan : définir le backlog et les priorités​

2.​ Do : développer et tester en continu​

3.​ Check : revue de sprint avec parties prenantes​

4.​ Act : rétrospective et ajustements​

Chaque sprint (1–4 semaines) produit un incrément fonctionnel déployable. Stand-up

quotidien pour synchroniser l’équipe.
🧪 Impact SDLC sur les tests
●​ Calendrier : tests en fin de cycle (Waterfall) vs. à chaque itération (Agile).​

●​ Documentation : lourde et formelle vs. allégée et adaptative.​

●​ Techniques : formelles (basées exigences) vs. exploratoires et automatisées.​

●​ Automatisation : limitée dans les séquentiels, intensive dans les agiles.​

●​ Rôle testeur : isolé en fin de cycle vs. intégré et collaboratif en Agile.​

✅ Bonnes pratiques QA
●​ Associer systématiquement une activité de test à chaque phase de développement.​

●​ Définir des objectifs clairs pour chaque niveau de test (unitaire, intégration, système,
acceptation).​

●​ Engager les testeurs dès la disponibilité des premières versions de documents

(shift-left).​

●​ Automatiser les tests de régression et smoke tests pour accélérer les cycles.​

❓ Choisir son SDLC

Il n’existe pas de “meilleur” modèle universel : tout dépend du contexte projet.

●​ Projets stables et bien définis : un modèle séquentiel peut suffire.​

●​ Projets nécessitant flexibilité et feedback rapide : privilégier Agile/itératif.​

●​ Mix possible : V-Model pour les composants back-end, Scrum pour l’interface
utilisateur.​

🎯 Conclusion : Adaptez vos tests au SDLC choisi : planifiez tôt, collaborez en continu, et
automatisez stratégiquement pour garantir qualité et valeur métier.
Les niveaux de test
Les logiciels sont constitués de plusieurs composants et sont développés à divers
niveaux.

🔹 1. Test de composants (ou tests unitaires)​

👨‍💻 Teste les plus petites unités du logiciel (fonctions, classes, modules).​
🎯 Objectif : détecter les défauts spécifiques dans chaque composant.​
🔧 Réalisé par les développeurs.
🔹 2. Test d’intégration des composants​
🔗 Vérifie les interactions entre les composants connectés.​
🧩 Permet de détecter des défauts liés à l’interface ou aux échanges de données.
🔹 3. Test système​
💻 Évalue le comportement global du logiciel comme un tout.​
✅ Inclut des tests fonctionnels, non fonctionnels, et des scénarios de bout en bout.
🔹 4. Test d’intégration du système​
🌐 Vérifie les interactions entre plusieurs systèmes ou services externes.​
📡 Exemple : votre logiciel communique-t-il bien avec une API tierce ?
🔹 5. Test d’acceptation​
📦 Réalisé par le client ou l’utilisateur final.​
🙋‍♀️ Vérifie si le logiciel répond aux besoins métiers et fonctionne comme attendu.​
🔹 Types :
●​ ✅ UAT (utilisateur) – fonctionnalités & processus métiers​

●​ ⚙️ Opérationnel – installation, sauvegarde, récupération​

●​ 📄 Contractuel / Réglementaire – conformité légale​

●​ 🧪 Alpha – tests internes (non développeurs)​

●​ 🧪 Bêta – tests externes (clients/utilisateurs)​

📌 À retenir pour l’examen

●​ Plus on teste tôt (composants), plus c’est rapide et moins coûteux à corriger.​

●​ ISTQB considère composant, unité et module comme synonymes.​

 ●​ L'intégration peut être faite entre 2, 3 ou 10 composants — ce qui compte,
c’est qu’ils interagissent.​

●​ Les tests d’acceptation ressemblent aux tests système, mais sont orientés
client/utilisateur.

Les tests comme moteur du développement logiciel

Dans cette partie, nous allons découvrir plusieurs bonnes pratiques du SDLC (Software
Development Life Cycle) qui placent les tests au centre du développement logiciel. L’ISTQB
identifie trois approches clés :

●​ ✅ TDD : Développement piloté par les tests​

●​ ✅ ATDD : Développement piloté par les tests d’acceptation​
●​ ✅ BDD : Développement guidé par le comportement​
Nous explorerons également :

●​ 🌐 DevOps et son intégration avec les tests​

●​ ⏪ Le concept de Shift-Left​
●​ 🔁 Les rétrospectives pour améliorer les processus​

1. 🧪 Les tests comme moteur du développement

Ces trois approches ont en commun une idée forte : les tests sont définis avant l’écriture
du code, ce qui favorise une démarche itérative, collaborative et orientée qualité.

🔴 TDD – Test Driven Development

Le développement commence par l’écriture d’un test unitaire qui échoue.

Cycle typique : Red – Green – Refactor

1.​ Red : Écrire un test (qui échoue)​

2.​ Green : Écrire juste assez de code pour que le test passe​
 3.​ Refactor : Réorganiser le code sans casser le test​

🎯 Objectif : Diriger le code par des cas de test, améliorer la conception logicielle au fur et
à mesure.

🟡 ATDD – Acceptance Test Driven Development

Tests écrits avant le développement, mais avec la participation des parties
prenantes (clients, testeurs, développeurs).

●​ Les tests d’acceptation expriment les besoins métier.​

●​ Ils sont souvent automatisés et servent de documentation vivante.​

🎯 Objectif : Garantir que les besoins du client sont compris et validés dès le départ.
🟢 BDD – Behavior Driven Development
Extension du TDD utilisant un langage naturel pour décrire le comportement
attendu.

●​ Format : Given – When – Then​

●​ Syntaxe Gherkin (ex. : Feature, Scenario, Given, When, Then)​

●​ Accessible à tous (même aux non-techniciens)​

🎯 Objectif : Aligner l’équipe autour du comportement attendu, en gardant une

communication claire.

2. ⚙️ DevOps et Tests
DevOps intègre développement, tests et opérations pour accélérer la livraison tout en
garantissant la qualité.

Avantages clés pour les tests :

●​ 🔁 Feedback rapide sur la qualité du code​

 ●​ 🧪 Tests automatisés intégrés à l’Intégration Continue (CI) et la Livraison
Continue (CD)​

●​ 🚀 Réduction des risques de régression​

●​ 📈 Meilleure visibilité sur les qualités non fonctionnelles (ex. : performance)​
💡 Attention : l’automatisation nécessite une infrastructure bien établie, des outils adaptés
et des compétences spécifiques.

3. ⏩ Approche Shift-Left
Le Shift-Left signifie : tester plus tôt dans le cycle de vie du logiciel.

✅ Bonnes pratiques :
●​ Revue de spécifications dès le début​

●​ Écriture de cas de test avant le code​

●​ Utilisation d’analyses statiques​

●​ Exécution de tests non fonctionnels le plus tôt possible​

●​ Intégration continue (CI) dès les premiers commits​

🎯 Objectif : Détecter les défauts tôt, réduire les coûts, améliorer la qualité globale.

4. 🔄 Rétrospectives et amélioration continue

Les rétrospectives permettent à l’équipe d’analyser ses pratiques et de s’améliorer en
continu.

📍 Moment : À la fin d’un sprint ou d’un projet​

👥 Participants : Toute l’équipe (testeurs, développeurs, PO, etc.)
Méthodologie : "Start – Stop – Continue"

●​ ✅ Start : Nouvelles pratiques à essayer​

●​ ❌ Stop : Ce qui ne fonctionne pas​
 ●​ 🔁 Continue : Ce qui fonctionne bien​
📊 Plan d’action avec des responsables désignés​
📈 Mesure de l’impact lors des prochaines rétrospectives

🏁 Résumé des bénéfices

✔️ Tests comme moteur du développement​
✔️ Détection précoce des anomalies​
✔️ Meilleure communication entre les rôles​
✔️ Livraison plus rapide et fiable​
✔️ Amélioration continue grâce aux rétrospectives

Types de tests
1. Tests fonctionnels

Les tests fonctionnels évaluent les fonctions qu’un composant ou un système doit exécuter.
Autrement dit, ils vérifient ce que le logiciel doit faire conformément aux exigences
fonctionnelles spécifiées.

Exemples :

●​ Un utilisateur peut-il se connecter à l’application avec des identifiants valides ?​

●​ La passerelle de paiement rejette-t-elle un numéro de carte invalide avec un

message d’erreur approprié ?​

●​ Le formulaire "Ajouter un nouvel enregistrement" permet-il bien l’insertion de

données dans la base ?​

2. Tests non fonctionnels

Ces tests vérifient si le système répond à des exigences non fonctionnelles telles que la
performance, la sécurité, ou l’utilisabilité. Il ne s’agit pas de ce que fait le système, mais
comment il le fait.

Exemple : Scénario d'une application bancaire mobile lors d'une mise à jour majeure
 ●​ Test de sécurité : Identifier les vulnérabilités pour protéger les données utilisateur.​

●​ Test de performance : Vérifier la fluidité pendant des pics de trafic (ex : jours fériés).​

●​ Test de convivialité (usabilité) : Recueillir des retours utilisateurs pour améliorer

l’interface.​

3. Tests boîte noire

Ces tests sont basés sur les spécifications externes du système. Le testeur ne connaît
pas la structure interne du code. Il se concentre uniquement sur les entrées et les sorties
attendues.

Synonymes : Test basé sur les spécifications, technique boîte noire

Exemple : Test de la fonctionnalité de connexion

●​ Test 1 : Connexion réussie avec identifiants valides​

●​ Test 2 : Connexion refusée avec mot de passe incorrect

4. Tests boîte blanche

À l’inverse des tests boîte noire, les tests boîte blanche s’appuient sur la structure interne
du logiciel : le code, les conditions, les boucles, etc. Ils sont souvent effectués par des
développeurs.

Exemple : Fonction de calcul de remises

●​ Cas : montantTotal = 150, estMembre = true​

●​ Attendu : 150 * 0.15 = 22.5​

5. Test de confirmation

Ces tests servent à vérifier qu’un défaut a bien été corrigé. Il s’agit d’exécuter les tests
qui échouaient auparavant ou d’en ajouter de nouveaux en lien avec la correction.

Exemple :

●​ Bug : La connexion échoue malgré des identifiants valides.​

●​ Correction : Fix sur la logique de validation du mot de passe.​

●​ Test : Vérifier la réussite de la connexion après correction.​

6. Test de régression

Les tests de régression garantissent que les modifications apportées n'ont pas causé de
nouveaux défauts ailleurs dans le système. Ce type de test est essentiel après des
corrections ou des évolutions logicielles.

Ils sont souvent automatisés car exécutés fréquemment, avec un périmètre qui s’élargit au
fil du temps.

Exemple :

●​ Objectif : Après plusieurs correctifs, vérifier que la connexion fonctionne toujours et

que d’autres fonctionnalités n'ont pas été affectées.​

Conclusion

Dans cette section, nous avons différencié les tests fonctionnels et non fonctionnels à
travers des exemples concrets.

●​ Boîte noire = test basé sur les spécifications, sans connaître le code →
généralement au niveau système.​

●​ Boîte blanche = test basé sur la logique interne → souvent au niveau unitaire.​

●​ Tests de confirmation et de régression peuvent intervenir à tous les niveaux, dès

qu’un changement ou une correction a lieu.​

🔧 Vue d'ensemble : Phase de Maintenance

🛠️
Ceci est un aperçu rapide, mais il couvre une phase très importante du cycle de vie
logiciel : la phase de maintenance .

🧱🙈
Dans certains cycles de vie, cette phase est totalement absente. On déploie en production…
et puis plus rien ! Le logiciel est « jeté par-dessus le mur » et oublié . Cela peut arriver
pour certains projets, mais la majorité nécessitent une maintenance continue. Un même

🔄.
logiciel peut être utilisé pendant 10, 20 ans, voire plus – mais il ne peut pas fonctionner
correctement sans entretien
🎯 Objectifs
Nous allons examiner deux éléments :

1️⃣ Quels sont les types de maintenance nécessaires et quels événements

déclenchent les tests de maintenance​
2️⃣ Quel est le rôle de l’analyse d’impact dans les tests de maintenance

🧪 Les tests de maintenance

Il existe plusieurs types de maintenance, chacun répondant à un besoin spécifique :

🔹 Maintenance corrective : Correction des défauts ou erreurs identifiés afin

d'assurer le bon fonctionnement du logiciel 🐛✅​
🔹 Maintenance adaptative : Adaptation aux changements d’environnement
compatibilité 💻🔄​
(système d’exploitation, matériel, mises à jour standards...) pour maintenir la

🔹 Maintenance préventive : Amélioration des performances, de la stabilité ou de

la maintenabilité pour éviter de futurs problèmes 🧹📈

🧠 Une analyse d’impact peut être réalisée avant un changement pour évaluer ses
conséquences potentielles sur le système.

🧭 Le périmètre des tests de maintenance dépend de :

●​ 🔸 Du niveau de risque du changement​

●​ 🔸 De la taille du système existant​

●​ 🔸 De l’ampleur du changement​

⚡ Déclencheurs des tests de maintenance

Les tests peuvent être déclenchés par :

●​ Des améliorations planifiées (ex. : migration d’un environnement à un autre)​

●​ Des tests de conversion de données​

 ●​ La mise hors service d’un système​

📚 Exemple pratique : Application de gestion de bibliothèque

Objectif :

Effectuer des tests de maintenance après des mises à jour.

✨ Modifications apportées :
●​ Nouvelle interface utilisateur 🎨​
●​ Correction des bogues dans la recherche de livres 🔍​
●​ Ajout d’une fonctionnalité de réservation de livres 📖🗓️​

✅ Cas de test 1 : Vérification de l’interface utilisateur

🔹 Étapes :
●​ Aller à la page d’accueil​

●​ Vérifier l’affichage des éléments UI (boutons, champs, etc.)​

●​ Vérifier les icônes et couleurs​

🔸 Résultat attendu : Interface conforme au design ✔️

🐞 Cas de test 2 : Vérification de la correction des bogues
🔹 Étapes :
●​ Aller à la recherche de livres​

●​ Rechercher "Python"​
 ●​ Vérifier l’affichage des résultats​

🔸 Résultat attendu : Résultats corrects, sans bogues 🧪🔍

📌 Cas de test 3 : Nouvelle fonctionnalité – Réserver un livre
🔹 Étapes :
●​ Aller à la fiche d’un livre​

●​ Cliquer sur « Réserver »​

●​ Remplir les infos : nom, date…​

●​ Cliquer sur « Confirmer »​

🔸 Résultat attendu : Réservation réussie + confirmation ✉️✅

🧾 Résumé
Les tests de maintenance sont essentiels pour :

●​ 📌 Vérifier que les mises à jour, corrections et nouvelles fonctionnalités

sont bien intégrées​

●​ ✅ Assurer que rien n’a été cassé dans le système existant​

●​ 🔁 Maintenir la qualité continue de l’application​

●​ 😌 Garantir une expérience utilisateur fluide et fiable