ISTQB V4

Certified Tester Foundation level

1 1

Jelassi Rayhane
2. Tests tout au long du cycle de vie du développement
logiciel
1. Tester dans le contexte d'un cycle de vie du développement logiciel

• Un modèle de cycle de vie du développement logiciel est une représentation abstraite et de haut
niveau du processus de développement logiciel.

• Un modèle de cycle de vie du développement logiciel définit la manière dont les différentes
phases de développement et les types d'activités réalisées sont liés les uns aux autres, à la fois
logiquement et chronologiquement.

Expression de Mise en
besoin Spécification Développement
production

• Exemples de modèles, on peut citer : les modèles de développement séquentiel (par exemple, le
modèle en cascade, le modèle en V), les modèles de développement itératif (par exemple, le
modèle en spirale, le prototypage) et les modèles de développement incrémental (par exemple, le
Processus Unifié). 2
2. Tests tout au long du cycle de vie du développement
logiciel

2.1. Tester dans le contexte d'un cycle de vie du développement logiciel

Modèle de cycle de vie en cascade Modèle de cycle de vie en V

1 3

3
2. Tests tout au long du cycle de vie du développement
logiciel

2.1. Tester dans le contexte d'un cycle de vie du développement logiciel

Modèle de cycle de vie en Spirale Méthode Agile

Les principes fondamentaux de l'agilité incluent la collaboration étroite
avec les clients ou les utilisateurs finaux, la capacité à répondre aux
changements et la livraison fréquente de versions fonctionnelles du
logiciel. Plutôt que de planifier tout le projet en détail au début et de le
suivre rigidement, l'approche agile encourage à travailler par petites
1 étapes, en4 ajustant constamment les priorités et les fonctionnalités à
développer en fonction des besoins actuels et des retours obtenus.

4
 2. Tests tout au long du cycle de vie du développement
logiciel
1. Tester dans le contexte d'un cycle de vie du développement logiciel

• Certaines activités au sein des processus de développement logiciel peuvent également être
décrites par des méthodes de développement logiciel plus détaillées et des pratiques Agile.

Exemples : développement piloté par les tests d'acceptation (ATDD),

• développement piloté par le comportement (BDD),
• conception pilotée par le domaine (DDD),
• programmation extrê1 me (XP), 5

• développement piloté par les fonctionnalités (FDD), Kanban, Lean IT, Scrum,
• et développement piloté par les tests (TDD).

5
 2. Tests tout au long du cycle de vie du développement
logiciel
Développement piloté par les tests d'acceptation (ATDD)

Les tests sont rédigés dans les User Stories coté utilisateur, grace au test on va répondre à la
problèmatique comment on va répondre ou besoin produit

On fera une réunion 3 amigos:

Product Owner ou son representant : C’est quoi notre besoin

1 6

L’équipe de développement : Comment on répond au besoin pour satisfaire la demande

Le QA (équipe Quality Assurance): Vérifier que l’on a traité la demande

Le développeur va developer en fonction de critères acceptance crée dans l’User Stories , une fois
que la fonctionnalité est crée les tests sont automatisé
6
 2. Tests tout au long du cycle de vie du développement
logiciel
Développement piloté par les tests d'acceptation (ATDD)

User story : en tant qu’utilisateur, je souhaite utiliser un champ de recherche pour saisir une ville, un nom ou une
rue, afin de trouver les options d’hôtel correspondantes.
Critères d’acceptation de l’interface de recherche de base
• Le champ de recherche est placé sur la barre supérieure
• La recherche démarre une fois que l’utilisateur clique sur « Rechercher »
• Le champ contient un espace réservé avec un texte en gris : « Où allez-vous ? »
• L’espace réservé disparaît une fois que l’utilisateur commence à taper
• La recherche est effectuée si un utilisateur saisit une ville, un nom d’hôtel, une rue ou tous
• La recherche est en angla1is, français, allemand et ukra7 inien
• L’utilisateur ne peut pas taper plus de 200 symboles
• La recherche ne prend pas en charge les symboles spéciaux (caractères). Si l’utilisateur a tapé un symbole
spécial, affichez le message d’avertissement : « L’entrée de recherche ne peut pas contenir de symboles
spéciaux.»

7
2. Tests tout au long du cycle de vie du développement
logiciel

Développement piloté par le comportement (BDD )

Exprime le comportement souhaité d’une application avec des cas de test

écrits dans une forme simple de langage naturel, qui est facile à
comprendre par les parties prenantes- en utilisant généralement le format

Given/When/Then(Etant donnée/lorsque/Alors)
1 8

On parle de langage GHERKING

-Les cas de test sont ensuite automatiquement traduits en tests

exécutables
8
2. Tests tout au long du cycle de vie du développement
logiciel

Programmation extreme (XP)

Méthode pour une équipe de maximum 20 personnes

-Une forte capacité de changement

-Test doivent réalisé qu plutôt

1

-Le client change souvent de besoin

-Être en présentiel

9
2. Tests tout au long du cycle de vie du développement
logiciel

Développement piloté par les fonctionnalités (FDD)

-Itération courte

-Liste des fonctionnalité

-Comment on va développer

-Prioriser les fonctionnalité

-Développer une partie de la fonctionnalité qu’on va livrer après l’itération

10
2. Tests tout au long du cycle de vie du développement
logiciel

Développement piloté par les fonctionnalités (FDD)

Méthode KANBAN:

-Méthode très utilisé

A faire En progression A tester Terminé

-Méthode agile
1

-Repose sur un système visuel

- Cycle itératif

-Le rôle de chacun est définit

11
 2. Tests tout au long du cycle de vie du développement
logiciel

Développement piloté par les fonctionnalités (FDD)

La méthode scrum répond au critéres suivants:
Méthode SCRUM:
Les rituels sont:
-Sprint Planning
-Daily
-Sprint Revue
-Retrospectives

1 12

Composition:
-Product Backlog
-Sprint Backlog

L’équipe Scrum:
Product Owner
-Equipe de développement et de test
-Scrum Master
12
2. Tests tout au long du cycle de vie du développement
logiciel

Développement piloté par les Tests (TDD)

-Une méthode qui Permet de porter les User stories par les tests,
autrement dit on va écrire les tests avant de développer la fonctionnalité.

-Il est utilisé en général dans une itération courte

1

13
2. Tests tout au long du cycle de vie du développement
logiciel

Conception piloté par les Domaines (DDD)

Le design piloté par le domaine (DDD) s’oppose à l’idée d’avoir un modèle unique et unifié pour
l’ensemble du système; il encourage plutôt à diviser le système en contexre délimité , chacun
ayant son propre modèle.

Pendant la phase stratégique de la conception, vous mappez le domaine d’entreprise et

1 14

définissez les limites de contexte de vos modèle de domaine

14
 2. Tests tout au long du cycle de vie du développement
logiciel
1. Tester dans le contexte d'un cycle de vie du développement logiciel

• Le test doit être adapté au cycle de vie du développement logiciel.

• Le choix du cycle de vie du développement logiciel a une incidence sur:
-Le périmètre et le calendrier des activités de test (par exemple, les niveaux de test et les types de
test).
-Le niveau de détail de la documentation des tests.
-Le choix des techniques de test et de l'approche de test.
-Le degré d'automatisati1on des tests.
-Le rôle et les responsabilités d'un testeur.

15
 2. Tests tout au long du cycle de vie du développement
logiciel
1. Tester dans le contexte d'un cycle de vie du développement logiciel

• Dans les modèles de développement logiciel séquentiel, les testeurs participe à l’analyse et à la
conception des tests.
• Les tests dynamiques sont généralement effectués à des étapes ultérieures. et tester
• Dans certains modèles de développement itératif et incrémentiel, chaque cycle fournit un
prototype fonctionnel ou une fonctionnalité de produit.
• Cela signifie que des tests statiques et dynamiques peuvent être effectués à chaque cycle.

• Dans le développement de logiciels agiles, il est préférable d’alléger la documentation des

produits de travail et d’utiliser une automatisation poussée des tests.
• Les tests manuels sont effectués à l'aide de techniques de test basées sur l'expérience et ne
nécessitent pas d'analyse ni de conception de tests préalables approfondies.

16
 2. Tests tout au long du cycle de vie du développement
logiciel

2.1.3. Cycle de vie du développement logiciel et bonnes pratiques de test

Les bonnes pratiques de test, indépendantes du modèle de cycle de vie du développement logiciel :
• Pour chaque activité de développement logiciel, il existe une activité de test correspondant

• Les différents niveaux de test ont des objectifs de test spécifiques et différents, ce qui permet aux tests
d'être suffisamment complets tout en évitant la redondance

• L'analyse et la conc1 eption des tests pour u1n7 niveau de test donné commencent pendant la phase de
développement correspondante du cycle du développement logiciel

• Les testeurs sont impliqués dans la revue des produits d'activités dès que les versions préliminaires de
cette documentation sont disponibles

17
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.4. DevOps et tests

• DevOps vise à permettre aux équipes de développement logiciel et d'exploitation de travailler ensemble.

• Cela nécessite un changement organisationnel et prend en charge des éléments culturels tels que
l’autonomie de l’équipe et un feedback rapide.

• Les pratiques techniques incluent l'intégration continue (CI) et la livraison continue (CD).

Avantages du point de vue des tests :

• Retour rapide et impact positif sur la qualité du code.

• Promouvoir l’approche shift-left et créer des environnements de test stables.
• Prise en charge des processus automatisés et visibilité accrue des exigences non fonctionnelles.
• Réduire le risque de régression grâce à des tests de régression automatisés

18
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.4. DevOps et tests

Défis:
• La nécessité de définir et d’établir un pipeline de livraison DevOps.
• Présentation et maintenance des outils CI/CD.
• L’automatisation des tests nécessite des ressources supplémentaires et est difficile à mettre en place.

Malgré un niveau élevé d'automatisation des tests, des tests manuels peuvent encore être nécessaires du
point de vue de l'utilisate1 ur.

19
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.5. Approche shift left

• Le principe du test précoce parfois appelé shift left parce qu'il s'agit d'une approche dans laquelle le test
est effectué plus tôt dans le cycle de vie du développement logiciel (SDLC).
• Le principe du shift left suggère normalement que les tests doivent être effectués plus tôt (par exemple,
sans attendre que le code soit implémenté ou que les composants soient intégrés), mais il ne signifie
pas que les tests doivent être négligés dans les phases ultérieures du cycle de vie du développement
logiciel
1 20

20
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.5. Approche shift left

Il existe quelques bonnes pratiques qui illustrent comment réaliser un "shift left" dans le test :

1. Examen de l'analyse du point de vue des tests.

2. Rédaction de scénarios de test avant d'écrire le code et d'exécuter le code dans une incubation de test.
3. Utilisation de CI ou même de CD.
4. Achèvement de l'analyse statique du code source.
5. Effectuer des tests n1on fonctionnels à partir d21u niveau de test des composants.

21
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.5. Approche shift left

• Le déplacement vers la gauche peut nécessiter une formation, des efforts et des coûts supplémentaires
au début du processus, mais peut permettre d'économiser de l'argent dans les étapes ultérieures.

• Il est important que les parties prenantes soient convaincues de l’approche du virage à gauche et croient
en ce concept.

22
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.6. Rétrospectives et amélioration de processus

• Les rétrospectives (également appelées "réunions post-projet" et rétrospectives de projet) sont souvent
organisées à la fin d'un projet ou d'une itération

• Lors d'une étape de livraison, ou peuvent être organisées en cas de besoin

• Lors de ces réunions, les participants (non seulement les testeurs, mais aussi, par exemple, les
développeurs, les ar1chitectes, le Product Own23
er, les analystes) discutent des points suivants:
• Qu'est-ce qui a été un succès et qui devrait être conservé ?
• Qu'est-ce qui n'a pas fonctionné et qui pourrait être amélioré ?
• Comment intégrer les améliorations et conserver les succès à l'avenir ?

23
 2. Tests tout au long du cycle de vie du développement
logiciel
2.1.6. Rétrospectives et amélioration de processus

• Les résultats doivent être enregistrés et font normalement partie du rapport de clôture des tests

Les avantages typiques pour les tests sont les suivants :

• Augmentation de I'efficacité et de I'efficience des tests
• Augmentation de la qualité du testware
• Consolidation de l'équipe et apprentissage
• Amélioration de la qu
1
alité de la base de test
• Amélioration de la coopération entre le développement et le test

24
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test

1 25

25
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test
Les tests composants
• Appelé aussi test unitaire, vise à vérifier le bon fonctionnement des composants d'un logiciel de manière
isolée pour s'assurer que chaque composant fonctionne correctement avant de les intégrer dans le
système global

Les tests d'intégration composants

Les tests d’intégration de composants sont des tests effectués pour découvrir des défauts dans les
interfaces et les interactions entre des composants intégrés. Ils visent à s’assurer du bon fonctionnement
des interactions et de l’interface entre différents composants. Ces tests sont généralement gérés par des
développeurs et permettent de vérifier si plusieurs unités de code fonctionnent bien ensemble

26
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test

Les tests système

• Se concentrent sur le comportement global et les capacités d'un système ou d'un produit entier, et
comprennent souvent des tests fonctionnels, des tâches de bout en bout et des tests non fonctionnels de
caractéristiques-qualité.

Les tests d'intégration du système

• Visent à tester les interfaces entre le système sous test et d'autres systèmes et services externes.
• Les tests d'intégration du système exigent des environnements de test appropriés, de préférence
similaires à l'environnement opérationnel.

27
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test

Les tests d'acceptation

• Sont axés sur la validation et la démonstration de l'aptitude au déploiement, ce qui signifie que le
système répond aux besoins métier de l'utilisateur.
• Les tests d'acceptation devraient être effectués par les utilisateurs prévus :

Les principales formes de 1

tests d'acceptation sont :
• les tests d'acceptation des utilisateurs (UAT)
• les tests d'acceptation opérationnelle,
• Les tests d'acceptation contractuels et réglementaires,
• Les tests alpha et les tests bêta.

28
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test

Test alpha :
Les tests alpha sont effectués sur le site de l'organisation qui développe, non pas par l'équipe de développement, mais
par des clients potentiels ou existants, et/ou des opérateurs ou une équipe de test indépendante.

Test Béta :
Les tests bêta sont effectués par des clients potentiels ou existants, et/ou des opérateurs sur leurs propres sites.
- Le test bêta peut venir après le test alpha, ou peut se produire sans qu'aucun test alpha précédent n'ait eu lieu.
- L'un des objectifs des tests alpha et bêta est de renforcer la confiance des clients potentiels ou existants et/ou des
opérateurs dans l’utilisation du système dans des conditions normales et quotidiennes et dans l'environnement
opérationnel pour atteindre leurs objectifs avec un minimum de difficulté, de coût et de risque.

29
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2. Niveaux de test et types de test
2.2.1. Niveaux de test

Liste utilisée pour séparer les niveaux de test :

• Objet de test.
• Objectifs du test.
• Base de test.
• Défauts et défaillances.
• Approche et responsabilités.

30
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2.2. Types de test

Le test fonctionnel (Le test de "ce que" le système doit faire.)

• évalue les fonctions qu'un composant ou un système doit remplir.
• Les fonctions sont "ce que" l'objet de test doit faire.
• L'objectif principal du test fonctionnel est de vérifier la complétude fonctionnelle, l'exactitude fonctionnelle
et l'adéquation fonctionnelle.

Le test non fonctionnel (Le

1
test de "comment" le système
31
se comporte. )
• évalue les attributs autres que les caractéristiques fonctionnelles d'un composant ou d'un système.
• Le test non fonctionnel est le test de "comment le système se comporte".
• L'objectif principal du test non fonctionnel est de vérifier les caractéristiques-qualité non fonctionnelles du
logiciel.

31
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2.2. Types de test
• Efficacité de la performance.
• Compatibilité.
• Utilisabilité.
• Fiabilité.
• Sécurité.
• Maintenabilité.
• Portabilité.

32
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2.2. Types de test

Le test boîte noire

• est basé sur les spécifications et dérive les tests de la documentation externe à l'objet de test.
• L'objectif principal du test boîte noire est de vérifier le comportement du système par rapport à ses
spécifications.

Le test boîte blanche

• est basé sur la structure
1
et dérive les tests de 33l'implémentation ou de la structure interne du système
(par exemple, le code, l'architecture, les flux métier et les flux de données).
• L'objectif principal du test boîte blanche est de couvrir la structure sous-jacente par les tests
jusqu'au niveau acceptable.

33
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2.3. Test de confirmation et test de régression

Test de confirmation :
• Ceci est fait pour confirmer que l’erreur d’origine a été corrigée avec succès.
• La version corrigée du logiciel est testée de différentes manières : en exécutant des scénarios
défectueux précédents ou en ajoutant de nouveaux tests.
• Elle peut être limitée en raison de contraintes de temps ou de coût, ou se limiter à la vérification de la
récurrence des erreurs.

Les tests de régression :

• Ceci est fait pour confirmer qu’un changement n’entraîne aucun effet négatif.
• Le changement peut affecter l'objet de test, d'autres composants et même d'autres systèmes connectés.
C'est un bon candidat pour l'automatisation des tests et il est recommandé de le démarrer dès les
premières étapes du projet.

34
 2. Tests tout au long du cycle de vie du développement
logiciel
2.2.3. Test de confirmation et test de régression

Tests de validation et de régression aux niveaux de test :

• Lorsque des bogues sont corrigés ou que des modifications sont apportées, elles doivent être effectuées
à tous les niveaux de test.
• Des tests de validation et/ou de régression sont requis à tous les niveaux de test.

35
 2. Tests tout au long du cycle de vie du développement
logiciel
2.3. Test de maintenance

Catégories d'entretien :
• La maintenance peut être corrective, adaptative ou améliorant les performances/maintenabilité.
• Cela peut inclure des versions/distributions planifiées et des versions/distributions non planifiées.

Analyse d'impact :
• Avant d’apporter des modifications, une analyse d’impact peut être effectuée pour évaluer les
conséquences possibles.
• Il est nécessaire de tester les modifications apportées au système dans un environnement réel et de
vérifier les régressions.
Portée du test de maintenance :
il Le degré de risque du changement, la taille du système existant et l'étendue du changement déterminent
la portée des tests de maintenance.

36
 2. Tests tout au long du cycle de vie du développement
logiciel
2.3. Test de maintenance

Déclencheurs de maintenance :
• Les modifications, les mises à niveau/migrations de l’environnement opérationnel et les retraits peuvent
déclencher une maintenance et des tests de maintenance.
• Les mises à niveau, les migrations et les dépréciations de l’environnement opérationnel peuvent
introduire des exigences de test particulières.

37