Préparation à la

certification ISTQB
Foundation Level

Enseignant : Marwen Tayechi

Introduction
Let’s start with the first set of slides
ISTQB

3
ISTQB Foundation Level

4
 ISTQB Foundation Level Exam
26
Pas de Réponses 1 seule
Examen 40 correctes réponse
marque
60 mn Questions pour correcte/
negartive question
réussir

Nombre De Questions Par Chapitre

Total
Ch. 1 Ch. 2 Ch. 3 Ch. 4 Ch. 5 Ch. 6

8 5 5 11 9 2 40

K1: se souvenir;
Nombre De Questions Par K Level
K2: comprendre; Total
K3: utiliser; K1 K2 K3 K4
K4: analyser 20 12 8 40
5
 Contenue du cours :

I. Fondamentaux des tests

II. Tester pendant le cycle de vie
du développement logiciel
III. Tests statiques
IV. Techniques de test
V. Gestion des tests
VI. Outils de support aux tests
6
1
Fondamentaux des
tests
 Fondamentaux des tests
Termes : couverture, débogage, défaut, erreur, défaillance, qualité, assurance qualité, cause racine, analyse de test, base de test, cas de
test, clôture des tests, condition de test, contrôle des tests, données de test, conception des tests, exécution des tests, planning de
l’exécution des tests, implémentation des tests, pilotage des tests, objet de test, objectif de test, oracle de test, planification des tests,
procédure de test, suite de test, test, testware, traçabilité, validation, vérification

1. Que sont les tests ?

2. Pourquoi les tests sont-ils nécessaires ?
3. Les 7 Principes généraux des tests
4. Processus de test
5. La psychologie des tests

8
 Que sont les tests ?
Les tests logiciels sont un moyen d'évaluer la qualité du logiciel et de réduire le risque de
défaillance du logiciel en cours de fonctionnement.

Certains tests impliquent l'exécution du composant ou du système testé. Ces tests sont
appelés tests dynamiques. D'autres tests n'impliquent pas l'exécution du composant
ou du système testé ; de tels tests sont appelés tests statiques.

Validation : confirmation par l’examen et la fourniture de preuves objectives que les

exigences, pour un usage ou une application voulue, ont été remplies. [ISO 9000]

Vérification : confirmation par l’examen et la fourniture de preuves objectives que des

exigences spécifiées ont été remplies. [ISO 9000]

9
 Que sont les tests ?
Objectifs des tests
· Évaluer les produits d’activités.
· Vérifier si toutes les exigences spécifiées ont été satisfaites
· Valider si l'objet de test est complet et fonctionne comme attendu
· Construire la confiance dans le niveau de qualité de l'objet de test
· Trouver et prévenir des défaillances et défauts
· Fournir suffisamment d'information aux parties prenantes pour la prise de décision
· Réduire le niveau de risque d'une qualité logicielle
· Se conformer aux exigences ou aux normes contractuelles, légales ou réglementaires

Les objectifs de test peuvent varier en fonction du contexte du composant ou du système

testé, du niveau de test et du modèle de cycle de vie de développement logiciel.
10
 Que sont les tests ?
Différence entre Test et débogage

➢ Le débogage est l'activité de développement qui trouve, analyse et corrige des

défauts.

➢ le test de confirmation vérifie si les corrections apportées ont résolu les défauts.

Dans certains cas, les testeurs sont responsables du test initial et du test de confirmation
final, tandis que les développeurs se chargent du débogage et du test des composants
concernés.

NB : Dans le développement Agile et dans d'autres cycles de vie, les testeurs peuvent
être impliqués dans le débogage et le test des composants.
11
Pourquoi les tests sont-ils nécessaires ?

les défauts augmenter

Essai Défauts sont la qualité
réparés du système
 Pourquoi les tests sont-ils nécessaires ?
participation des testeurs

▪ La participation des testeurs à la revue des exigences ou au raffinement des User Stories pourrait
permettre de détecter des défauts dans ces produits d’activités. L'identification et l'élimination des
défauts dans les exigences réduit le risque de développement de fonctionnalités incorrectes ou non
testables.
▪ Le fait que les testeurs travaillent en étroite collaboration avec les concepteurs du système pendant la
conception du système peut aider chaque partie à mieux comprendre la conception et la façon de la
tester. Cette meilleure compréhension peut réduire le risque de défauts de fond dans la conception et
permettre d'identifier les tests à un stade précoce
▪ Le fait que les testeurs travaillent en étroite collaboration avec les développeurs pendant que le code est
en cours de développement peut augmenter la compréhension du code et de la façon de le tester par
chaque partie. Cette meilleure compréhension peut réduire le risque de défauts dans le code et les tests.
▪ Le fait que les testeurs vérifient et valident le logiciel avant sa sortie permet de détecter des défaillances
qui auraient pu être manquées et aide au processus d'élimination des défauts ayant causé les
défaillances (c.-à-d. le débogage). Cela augmente la probabilité que le logiciel réponde aux besoins des
parties prenantes et satisfasse les exigences
 Pourquoi les tests sont-ils necessaires ?
Assurance qualité et test

Gestion de la
qualité

Empêcher Je fais
Assurance Contrôle de toutes
l'apparition de
qualité qualité sortes de
l'erreur
tests

❖ Se concentrer sur le processus ❖ L’accent du produit (la concentration sur le produit)

❖ Créer des produits de haute qualité ❖ Trouver des défauts
❖ Prévention des défauts « wi9aya mil ❖ Engagement à court terme
3oyoub »
❖ Engagement à long terme
15
 Pourquoi les tests sont-ils nécessaires ?
Erreurs, défauts et défaillances

➢ Une personne peut faire une erreur, ce qui peut conduire à l'introduction d'un défaut (faute
ou bogue) dans le code du logiciel ou dans un autre produit d’activités connexe. Si un
défaut dans le code est exécuté, cela peut causer une défillance.
.

16
 Pourquoi les tests sont-ils nécessaires ?
Erreurs, défauts et défaillances

➢ Les faux positifs : peuvent se produire en raison d'erreurs dans la façon dont les tests ont
été exécutés, ou en raison de défauts dans les données de test, l'environnement de test, ou
d'autres testware, ou pour d'autres raisons.
Les faux positifs sont signalés comme des défauts, mais ne sont en réalité pas des défauts

Ex 1 : lors de l'ajout d'un numéro de mobile avec 7 au lieu de 8 puis essayez d'appeler, le système se bloque

(erreur de l'utilisateur).

Ex 2 : essayer d'appliquer la même application sur de nouvelles fenêtres et avoir des erreurs
Les faux négatifs : sont des tests qui ne détectent pas les défauts qu'ils auraient dû détecter.

les faux positifs sont signalés comme des défauts, mais ne sont en réalité pas des défauts. (tu ne dis pas
défaut et c'est défaut) .

Ex : peut vérifier un nouveau compte après plusieurs jours et la norme est de 30 minutes.
 Pourquoi les tests sont-ils nécessaires ?
Défauts, causes racines et effets

Les causes racines des défauts sont les premières actions ou conditions qui ont contribué à la
création des défauts.

▪ Les contraintes de temps

▪ La faillibilité humaine (L'homme fait des erreurs par nature)
▪ L’inexpérience ou le manque de compétence des participants au projet
▪ Une mauvaise communication entre les participants au projet
▪ La complexité du code, de la conception, de l'architecture, du problème sous-jacent à résoudre, et/ou des technologies
utilisées

▪ Les malentendus sur les interfaces intra-système et inter-système, en particulier lorsque de telles interfaces intra-système et
inter-système sont très nombreuses
▪ Des technologies nouvelles, peu connues
▪ Conditions environnementales. 14
 7 principes sur les tests
1 . Les tests montrent la présence de défauts, pas leur absence
Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Les
tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun
défaut n’est découvert, ce n’est pas une preuve que tout est correct.
2 . Les tests exhaustifs sont impossibles
Tout tester (toutes les combinaisons d’entrées et de préconditions) n’est pas faisable sauf pour des
cas triviaux. Plutôt que de chercher à faire tests exhaustifs, l’analyse des risques, des techniques de
test et des priorités devraient être utilisés pour cibler les efforts de tests.
3. Tester tôt économise du temps et de l’argent
Pour détecter tôt les défauts, à la fois des activités de tests statiques et des activités de tests
dynamiques doivent être lancées le plus tôt possible dans le cycle de vie de développement du
logiciel. Le fait de tester tôt est parfois appelé " shift left ". Tester tôt dans le cycle de vie du
20
développement logiciel permet de réduire ou d'éliminer des changements coûteux
4. Regroupement des défauts
Un petit nombre de modules contient généralement la plupart des défauts découverts lors des
tests avant livraison, ou est responsable de la plupart des défaillances en exploitation. Des
regroupements prévisibles de défauts, ou des regroupements réellement observés en test ou en
exploitation, constituent un élément important de l'analyse des risques utilisée pour cibler l'effort
de test (comme mentionné dans le principe 2).
5. Paradoxe du pesticide
Si les mêmes tests sont répétés de nombreuses fois, le même ensemble de cas de tests finira par
ne plus détecter de nouveaux défauts. Pour détecter de nouveaux défauts, il peut être nécessaire
de modifier les tests existants et les données de test existantes, ainsi que de rédiger de nouveaux
tests. (Les tests ne sont plus efficaces pour détecter des défauts, tout comme les pesticides ne
sont plus efficaces pour tuer les insectes après un certain temps). Dans certains cas, comme les
tests de régression automatisés, le paradoxe du pesticide a un résultat bénéfique, qui est le
nombre relativement faible de défauts de régression.
6. Les tests dépendent du contexte

Les tests sont effectués différemment dans des contextes différents. Par exemple, un logiciel de

contrôle industriel, critique au niveau de la sureté, sera testé différemment d’une application de

commerce électronique sur téléphone mobile. Comme autre exemple, le test dans un projet Agile est

effectué différemment du test dans un projet à cycle de vie séquentiel (voir section 2.1).

7. L’absence d’erreurs est une illusion (lwahm)

Certaines organisations s'attendent à ce que les testeurs puissent effectuer tous les tests possibles

et trouver tous les défauts possibles, mais les principes 2 et 1, respectivement, nous disent que c'est

impossible. De plus, il est illusoire (c.-à-d. une croyance erronée) de s'attendre à ce que le simple fait

de trouver et de corriger un grand nombre de défauts garantisse la réussite d’un système.

Questions de révision

24
Processus de test
Activités et taches de test

25
 Processus de test
Le processus de test dans le contexte

Les facteurs qui influencent le processus de test :

· Le modèle de cycle de vie du développement logiciel et les méthodologies de projet utilisées
· Les niveaux de test et types de test prévus
· Les risques liés aux produits et aux projets
· Le domaine d'activité
· Les contraintes opérationnelles, entre autres :
-Les budgets et ressources
-Les délais
-La complexité
-Les exigences contractuelles et réglementaires
· Les politiques et pratiques organisationnelles
18
· Les normes internes et externes requises
 Processus de test
Activités et taches de test

Planification des tests

La planification des tests implique de définir les objectifs du test , date de début et fin ,et l'approche
retenue pour atteindre les objectifs du test dans le respect des contraintes imposées par le contexte.

Pilotage et contrôle des tests

la comparaison régulière de l’avancement réel par rapport au plan de test à l'aide des métriques de
pilotage définies dans le plan de test.
Le contrôle des tests consiste à prendre les mesures nécessaires pour satisfaire aux objectifs du
plan de test (qui peut être mis à jour au fil du temps). Le pilotage et le contrôle des tests se basent
sur l'évaluation des critères de sortie
27
 Processus de test
Activités et taches de test
Analyse de test : "quoi tester"

Analyser les bases de test pour identifier les caractéristiques testables et définir les conditions de test
associées.
L'analyse de test comprend les principales activités suivantes :
▪ Analyser les bases de test
▪ Evaluer les bases de test et des éléments de test pour identifier des défauts de différents types
(Ambiguïtés . . . Omissions . . . Incohérences . . . inexactitudes . . . Contradictions déclarations superflues)
▪ Identifier les caractéristiques et les ensembles de caractéristiques à tester
▪ Définir et prioriser les conditions de test pour chaque caractéristique (fonctionnelles, non-
fonctionnelles et structurelles, facteurs métier et techniques, niveaux de risque)
▪ Capturer la traçabilité bidirectionnelle entre les bases de test et les conditions de test
28
 Processus de test
Activités et taches de test
Conception des tests : « comment tester ? »

Convertir les conditions de test en cas de test :

 Conditions de Cas de test de Cas de test
test haut niveau détaillés

Condition de test : ajouter utilisateur ,modifier utilisateur /photo utilisateur et champs obligatoires

Cas de test de haut niveau (scénarios) : vérifier l'ajout de l'utilisateur/vérifier l'édition de l'utilisateur
vérifier le téléchargement de la photo de l'utilisateur/vérifier les champs obligatoires
d'enregistrement
de l'utilisateur
Cas de test détaillés : Scénario de test /suite /haut niveau cas de test
Télécharger la photo jpg puis vérifier
l'ajustement de la photo dans le cadre
Télécharger la photo png puis vérifier
Vérifier télécharger la photo de l'ajustement de la photo dans le cadre
l'utilisateur Télécharger la photo gif puis vérifier
l'ajustement de la photo dans le cadre
Télécharger une photo de moins de 2 M
Télécharger une photo égale de 2 M

Télécharger une photo plus haut 2 M

 Processus de test
Activités et taches de test
Conception des tests : « comment tester ? »
les conditions de test sont déclinées en cas de test de haut niveau et autres testware.

La conception des tests comprend les activités principales suivantes :

· Concevoir et prioriser les cas de test et les ensembles de cas de test

· Identifier les données de test nécessaires pour les conditions de test et les cas de test
· Concevoir l'environnement de test et identifier l'infrastructure et les outils nécessaires
· Etablir la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas de test

31
 Processus de test
Activités et taches de test
Implémentation des tests : « Est-ce que tout est en place pour exécuter les tests ? ».

Créer et/ou compléter le testware nécessaire à l'exécution des tests , y compris l'ordonnancement des cas de
test en procédures de test.

L'implémentation des tests comprend les activités principales suivantes :

▪ Développer et prioriser les procédures de test et créer des scripts de test automatisés.
▪ Créer des suites de tests à partir des procédures de test et des scripts de tests automatisés.
▪ Positionner les suites de tests dans un calendrier d'exécution des tests.
▪ Construire l'environnement de test (harnais de test, la virtualisation des services, les simulateurs ..)
▪ Préparer les données de test.
▪ Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas
de test, les procédures de test et les suites de tests. 22
 Processus de test
Activités et taches de test
Exécution des tests
les suites de tests sont exécutées conformément au calendrier d'exécution des tests.

L'exécution des tests comprend les activités principales suivantes :

▪ Enregistrer les IDs et les versions des éléments de l'objet et des outils de test et des testware.
▪ Exécuter les tests manuellement et/ou automatiques.
▪ Comparer les résultats obtenus avec les résultats attendus
▪ Analyser les anomalies/défaillance afin d'établir leurs causes probables
▪ Signaler les défauts sur la base des défaillances observées
▪ Enregistrer les résultats de l'exécution des tests (par exemple, réussite, échec, blocage)
▪ Répéter certaines activités de test (suite:anomalie, test corrigé, test de confirmation, test de régression)
▪ Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas
de test, les procédures de test et les résultats des tests. 23
 Processus de test
Activités et taches de test
Clôture des tests

Collecter les données des activités de test terminées afin de consolider l'expérience, les testware et toute
autre information pertinente. Les activités de clôture des tests ont lieu à des jalons du projet; qu'une itération
de projet Agile est terminée; qu'un niveau de test ou qu'une maintenance est terminée.

La clôture des tests comprend les activités principales suivantes :

▪ Vérifier si tous les rapports de défauts sont clôturés, et saisir des demandes de modification ou des
items du backlog du produit pour tous les défauts non résolus à la fin de l'exécution des tests
▪ Créer un rapport de synthèse de test à communiquer aux parties prenantes
▪ Finaliser et archiver l’environnement, les données, l'infrastructure de test et autres.
▪ Remettre le testware aux équipes de maintenance, équipes de projet ou à d'autres parties.
▪ Analyser les leçons apprises et utiliser l'information recueillie pour améliorer le processus de test 24
Processus de test
Les produits d’activités du test

35
 Processus de test
Traçabilité entre les bases de test et les produits d’activités du test
Une bonne traçabilité facilite :

▪ L’analyse de l'impact des changements

▪ L’audit des tests
▪ La satisfaction des critères de gouvernance IT
▪ L’amélioration du caractère compréhensible des rapports d'avancement des tests et des rapports de
synthèse de test afin d'y inclure l'état des éléments des bases de test
▪ La restitution des aspects techniques des tests aux parties prenantes en des termes qu'elles peuvent
comprendre
▪ L’apport d’information pour évaluer la qualité du produit, l’aptitude du processus et l'avancement du
projet par rapport aux objectifs métier

36
 La psychologie des tests
Psychologie humaine et test
➢ Commencer par la collaboration plutôt que par la confrontation . Rappeler à tous l'objectif commun d'une meilleure
qualité des systèmes.

➢ Mettre l'accent sur les bénéfices du test. Par exemple, pour les auteurs, l'information sur les défauts peut les aider à
améliorer leurs produits d’activités et leurs compétences. Pour l'organisation, les défauts trouvés et corrigés durant
les tests permettront d'économiser du temps et de l'argent et de réduire le risque global pour la qualité du produit.

➢ Communiquer les résultats des tests et d'autres constats d'une manière neutre et axée sur les faits, sans critiquer la
personne qui a créé l’item défectueux. Rédiger des rapports objectifs et factuels sur les défauts et les constats des
revues.

➢ Essayer de comprendre ce que ressent l'autre personne et les raisons pour lesquelles elle peut réagir négativement
à l'information.

27
➢ Confirmer que l'autre personne a compris ce qui a été dit et vice versa.
 La psychologie des tests
Etat d’esprit des testeurs et des développeurs
L'objectif premier du développement est de concevoir et de construire un produit.
les objectifs du test comprennent la vérification et la validation du produit, la détection des défauts avant
la livraison.
✓ L’union de ces points de vue permet d'atteindre un niveau plus élevé de qualité des produits.

L'état d'esprit d'un testeur devrait inclure : la curiosité, un pessimisme professionnel, un œil critique,
l'attention aux détails et une motivation pour de bonnes et positives communications et relations

L'état d'esprit d'un développeur peut inclure certains éléments de l'état d'esprit d'un testeur.
Avec le bon état d'esprit, les développeurs sont capables de tester leur propre code.

38
Questions de révision

39
 Tester pendant le
2 cycle de vie du
développement
logiciel
 Tester pendant le cycle de vie du
développement
Termes : couverture, test d'acceptation, test alpha, test bêta, logiciel commercial sur étagère (COTS), test d'intégration de composants,
test de composants, test de confirmation, test d'acceptation contractuelle, test fonctionnel, analyse d'impact, test d'intégration, test de
maintenance, test non-fonctionnel, test d'acceptation opérationnelle, test de régression, test d'acceptation réglementaire, modèle de
développement séquentiel, test d'intégration de systèmes, test système, bases de test, cas de test, environnement de test, niveau de
test, objet de test, objectif de test, type de test, test d'acceptation utilisateur, test boîte blanche.

1. Les modèles de développement logiciel

2. Niveaux de test
3. Types de test
4. Tests de maintenance

41
 Les modèles de développement logiciel
Développement de logiciel et tests logiciels
✓ Chaque modèles de cycle de développement de logiciels nécessite une approches de test.
✓ Pour chaque activité de développement, il y a une activité de test correspondante.
✓ L'analyse et la conception et les revus des tests pour un niveau de test donné commencent au cours de
l'activité de développement correspondante ; dès que des versions préliminaires sont disponibles.
✓ Quel que soit le modèle de cycle de développement logiciel choisi, les activités de test devraient
commencer dès les premières étapes du cycle de vie, en respectant le principe de « Tester tôt ».

✓ les modèles de cycle de vie de développement de logiciels courants comme suit :

42
 Les modèles de développement logiciel

45
Modèle en cascade et appelé aussi <<Modèle linéaire>>:
▪ Le résultat de chaque phase est un ensemble de livrables
▪ Une phase ne peut démarrer que si la précédente est finie
Dans ce modèle, les activités de test ont seulement lieu une fois que toutes les autres activités de
développement sont terminées.

46
Le modèle en V :
▪ Variante du modèle en cascade qui fait l’accent sur la vérification et la validation
▪ Le test du produit se fait en parallèle par rapport aux autres activités

34
le modèle itératif

▪ Le processus d'établissement des exigences, de conception, de construction et de test d'un

système, réalisé sous la forme d'une série de cycles de développement plus courts.

▪ Exemples : prototypage, développement rapide d'applications (RAD), processus unifié rationnel

(RUP) et modèles de développement agiles.

▪ Une caractéristique commune des approches itératives est que la livraison est divisée en

incréments ou builds , chaque incrément ajoutant de nouvelles fonctionnalités.

▪ L'incrément produit par itération peut être testé à plusieurs niveaux dans le cadre de son

développement.

▪ Un incrément, ajouté à d'autres développés précédemment, forme une partie croissante

50
 Backlog Backlog-les exigences

Itération1 : Conception-code-test
Login Login,sign up, items Retester-Régression

Sign Up Iteration2: Conception-code-test

Gestion du panier Retester-Régression
Items 1+2
Iteration3: Conception-code-test
Gestion du panier Passer des Retester-Régression
commandes 1+2+3
Passer des commandes Conception-code-test
Iteration4:
paiements Retester-Régression
Paiements 1+2+3+4
Iteration5: Conception-code-test
livraison livraison Retester-Régression
1+2+3+4+5
Régression complète du système
Le modèle agile
▪ Le modèle agile est une combinaison de modèles de processus itératifs et incrémentiels axés sur
l'adaptabilité des processus et la satisfaction des clients grâce à la livraison rapide d'un produit
logiciel fonctionnel.
▪ Les méthodes agiles divisent le produit en petites versions incrémentielles.
▪ Ces builds sont fournis par itérations.
▪ Prendre beaucoup de temps 2 m 2 w

Sur les processus et les outils Individu et interaction

sur une documentation complète le programme fonctionne

sur la négociation du contrat Coopération client

suivre un plan Répondre au changement

37
Le modèle Scrum
le Scrum est un sous-ensemble d'agile, le modèle suggère que les projets progressent via une
série de sprints, conformément à une méthodologie agile, les sprints sont limités à un mois
maximum, le plus souvent deux semaines
 Planification
Sprint 3 :
❖Paiements
❖livraison 03

Sprint 1:
❖Login
02 Sprint 2:
❖ Gestion du panier
Période de ❖Sign Up ❖ Passer des commandes
❖Gérer profil
préparation
01
0

11
Méthodologie: SCRUM
Meilleure communication et
Meilleure visibilité.

Les risques sont détectés

et L’acceptation de
changement.

Un produit de haute qualité

Les modèles de cycle de vie du développement logiciel eux-mêmes peuvent être combinés.

Exemple : Les systèmes Internet des Objets (IoT – Internet of Things), qui se composent de nombreux objets
différents, tels que des équipements, des produits et des services, appliquent généralement des modèles de
cycle de développement logiciel distincts pour chaque objet.

59
 Niveaux de test
Les niveaux de test utilisés dans ce syllabus sont les suivants :

60
Niveaux de test
Test de composants TDD : Test first

61
Niveaux de test
Test d'intégration

62
 Niveaux de test
Test d'intégration

L’intégration "big bang" des composants: veut dire que l'intégration de tous les composants ou
systèmes s’effectue en une seule étape.

L’intégration incrémentale des composants veut dire que l'intégration se fait par petit nombre de
composants.

Une analyse de risque des interfaces les plus complexes peut aider à focaliser les tests d'intégration.

63
Niveaux de test
Test système

64
Niveaux de test
Test d'acceptation

65
Niveaux de test
Test d'acceptation

66
Questions de révision

67
 Types de test
Tests fonctionnels / Tests non fonctionnels

68
 Types de test
Tests fonctionnels /non fonctionnels

Tests
fonctionnels

Tests
Non
fonctionnels

69
 Types de test
Tests boîte-blanche / Tests de confirmation / Tests de régression
Tests boîte-blanche : des tests basés sur la structure ou l'implémentation interne du système. La
structure interne peut comprendre le code, l'architecture, les flux de travail et/ou les flux de données au

sein du système (couverture de code)

Tests liés aux changements : Lorsque des modifications sont apportées à un système, que ce soit pour
corriger un défaut ou en raison d'une fonctionnalité nouvelle ou modifiée, des tests devraient être
effectués pour confirmer que les modifications ont corrigé le défaut ou implémenté la fonctionnalité
correctement, et n'ont pas causé de conséquences préjudiciables inattendues.
• Test de confirmation : refaire les cas de test qui ont échoué en raison du défaut
• Tests de régression : Tester si une correction a accidentellement affecté le comportement d'autres
parties du code
Des tests de confirmation et de régression sont effectués à tous les niveaux de test.
70
 Tests de maintenance
Une fois déployés dans les environnements de production, les logiciels et les systèmes doivent être
maintenus.
Des changements dans les logiciels et les systèmes livrés pour ;
✓ Corriger des défauts découverts lors de l'utilisation opérationnelle
✓ Ajouter de nouvelles fonctionnalités, soit pour supprimer ou modifier des fonctionnalités déjà
livrées.
✓ La maintenance est également nécessaire pour préserver ou améliorer les caractéristiques de
qualité non fonctionnelles en particulier la performance, la compatibilité, la fiabilité, la sécurité et la
portabilité.
✓ Le déclassement, par exemple lorsqu'une application arrive en fin de vie

Lorsqu'une application ou un système est mis hors service, il peut être nécessaire de tester la migration ou
l'archivage des données si de longues périodes de conservation des données sont nécessaires. Il peut
également être nécessaire de tester les procédures de restauration/récupération après l'archivage pour de
longues périodes de conservation 50
 Analyse d'impact pour la maintenance
L'analyse d'impact évalue les changements qui ont été apportés afin d'identifier les conséquences
prévues ainsi que des effets secondaires attendus et possibles d'un changement, et d'identifier les
zones du système qui seront affectées par le changement.

L'analyse d'impact peut être difficile si :

✓ Les spécifications (p. ex., exigences métier, User Stories, architecture) sont obsolètes ou
manquantes
✓ Les cas de test ne sont pas documentés ou sont obsolètes
✓ La traçabilité bidirectionnelle entre les tests et les bases de test n'a pas été maintenue
✓ Le support de l'outillage est faible ou inexistant
✓ Les personnes impliquées n'ont pas de connaissance du domaine et/ou du système
✓ Une attention insuffisante a été accordée à la maintenabilité du logiciel au cours du
51
développement
Questions de révision

52
3
Tests
statiques
 Tests statiques
Termes : revue ad hoc, revue basée sur des check-lists, test dynamique, revue formelle, revue informelle, inspection, relecture basée sur
la perspective, revue, revue basée sur les rôles, revue basée sur des scénarios, analyse statique, test statique, revue technique, relecture
technique.

1. Bases des tests statiques

2. Processus de revue

54
 Tests statiques
Bases des tests statiques
Presque tous les produits d'activités peuvent être examinés à l'aide de tests statiques (revues et/ou
analyses statiques), par exemple :
· Les spécifications : les exigences métier, les exigences fonctionnelles et les exigences de sécurité
· Les épics, User Stories, et critères d’acceptation
· Les spécifications d'architecture et de conception
· Le code
· Le testware ; les plans de test, les cas de test, les procédures de test et les scripts de test automatisés
· Les guides utilisateur
· Les pages Web
· Les contrats, les plans de projet, les calendriers et les budgets
· Les modèles, tels que les diagrammes d'activité, qui peuvent être utilisés pour les tests basés sur des

modèles 55
 Tests statiques
Bases des tests statiques
Contrairement aux tests dynamiques, qui nécessitent l'exécution du logiciel testé, les tests statiques
reposent sur l'examen manuel des produits d’activités (c.-à-d. les revues) ou sur une évaluation outillée du
code ou d'autres produits d’activités (c.-à-d. l'analyse statique). Les deux types de tests statiques évaluent
le code ou tout autre produit d’activités testé sans exécuter réellement le code ou le produit d’activités testé.

Les revues varient d’infor m elles à formelles. La focalisation d'une revue dépend des objectifs fixés pour la
revue trouver des défauts
gagner en compréhension
former les participants tels que des testeurs et de nouveaux membres de l'équipe
discuter et décider par consensus
Un même produit d’activités peut faire l'objet de plus d'un type de revue. Si plus d'un type de revue est utilisé,
l'ordre peut varier. Par exemple, une revue informelle peut être effectuée avant une revue technique, afin de
56
s'assurer que le produit d’activités est prêt pour une revue technique.
 Tests statiques
Bénéfices des tests statiques

· Détection et correction plus efficace des défauts, avant l'exécution des tests dynamiques
· Identification des défauts qui ne sont pas facilement décelables par des tests dynamiques
· Prévention des défauts de conception ou de codage par la découverte d'incohérences, d'ambiguïtés, de
contradictions, d'omissions, d'inexactitudes et de redondances dans les exigences
· Augmentation de la productivité du développement (par exemple, grâce à une meilleure conception, à
un code plus facile à maintenir)
· Réduction des coûts et des délais de développement
· Réduction des coûts et des délais des tests
· Réduction du coût total de la qualité tout au long de la durée de vie du logiciel (réduction du nombre de
défaillances plus tard dans le cycle de vie)
· Amélioration de la communication entre les membres de l'équipe au cours de la participation aux revues
57
 Tests statiques
Les défauts détectés des tests statiques
· Défauts dans les exigences (p. ex. incohérences, ambiguïtés, contradictions, omissions, inexactitudes et
redondances)
· Défauts dans la conception (p. ex. algorithmes ou structures de base de données inefficaces,
taux de dépendance élevé, faible cohésion)
· Défauts dans le code (p. ex. variables avec des valeurs non définies, variables déclarées mais
jamais utilisées, code inatteignable, code dupliqué)
· Ecarts par rapport aux normes (p. ex. non-respect des règles de codage)
· Spécifications d'interface incorrectes (p. ex. unités de mesure utilisées par le système appelant
différentes de celles utilisées par le système appelé)
· Vulnérabilités de sécurité (p. ex. sensibilité aux débordements de la mémoire tampon)
· Lacunes ou inexactitudes dans la traçabilité ou la couverture des bases de test (p. ex., des tests
manquants pour un critère d'acceptation)
58
** Code mort : code inatteignable
 Tests statiques
Processus de revue
· Définir le périmètre et estimer l'effort et le temps requis
· Identifier les caractéristiques de la revue ; type de revue avec les rôles, les activités et les checklists
Planification · Sélectionner les personnes et attribuer des rôles
· Définir des critères d'entrée et de sortie pour les types de revue plus formels (p. ex. inspections)
· Vérifier que les critères

Lancement de la revue · Distribuer le produit d'activités revu.

· Expliquer le périmètre, les objectifs, le processus, les rôles et les produits d'activités aux participants
· Revoir tout ou partie du produit d'activités
Revue individuelle
· Noter les défauts potentiels, les recommandations et les questions
· Communiquer les défauts potentiels identifiés
· Analyser les défauts potentiels, leur affecter un responsable et un statut
Communication et
· Évaluer et documenter les caractéristiques de qualité
analyse des problèmes
· Évaluer les résultats de la revue en fonction des critères de sortie pour prendre une décision de revue
(rejet ; changements majeurs nécessaires ; acceptation, avec ou sans des changements mineurs)
· Produire des rapports de défauts et les communiquer a la personne ou à l'équipe concernée.
· Corriger les défauts trouvés (correction généralement réalisée par l'auteur) dans le produit d'activités
revu.
Correction et
· Enregistrer l'état actualisé des défauts (dans les revues formelles)
production de rapports
· Recueillir des métriques (pour les types de revue plus formels)
· Vérifier que les critères de sortie sont satisfaits (pour les types de revue plus formels)
· Accepter le produit d'activités lorsque les critères de sortie sont satisfaits 59
 Tests statiques
Techniques de revue individuelle

Ad hoc : les réviseurs reçoivent peu ou pas de directives sur la façon dont cette
Tâche devrait être accomplie. Elle dépend fortement des compétences des réviseurs.
Basée sur les check-lists : Une technique systématique, pour laquelle les réviseurs détectent
les problèmes sur la base de check-list.
Scénarios et essais à blanc : Une approche fondée sur des scénarios aide les réviseurs à
effectuer des "essais à blanc" sur le produit d’activités en fonction de son utilisation prévue.
Basée sur les rôles : les réviseurs évaluent le produit d’activités du point de vue de rôles
individuels des parties prenantes.
Basée sur la perspective : les réviseurs adoptent différents points de vue des parties prenantes
dans le cadre d'une revue individuelle.

60
 Tests statiques
Rôles et responsabilités dans une revue formelle
Auteur · Crée le produit d'activités revu et corrige les défauts (si nécessaire)

· Décide de la mise en œuvre et planifie la revue · Affecte le personnel, le budget et le temps

· Vérifie le rapport coût-efficacité en continu
Manager · Met en œuvre les mesures appropriées en cas de résultats inadéquats

· Assure le bon déroulement des réunions de revue

· Fait la médiation, si nécessaire, entre les différents points de vue
Facilitateur (modérateur)
la personne dont dépend le succès de la revue

· Prend la responsabilité générale de la revue

Responsable de la revue · Décide qui sera impliqué et organise quand et où elle aura lieu
· Il peut s'agir d'experts du domaine, de personnes travaillant sur le projet, d'intervenants ayant un intérêt pour le
produit d’activités et/ou de personnes ayant des compétences techniques ou métier spécifiques
· Ils identifient les défauts potentiels du produit d’activités à revoir
· Ils peuvent représenter différentes perspectives (p. ex. testeur, programmeur, utilisateur, opérateur, analyste
Réviseurs
métier, expert en utilisabilité, etc.).

· Recueille les défauts potentiels découverts au cours de l'activité de revue individuelle

· Enregistre les nouveaux défauts potentiels, les points en suspens et les décisions prises lors de la réuni 6d1e
Scribe (ou rapporteur)
revue (durant son déroulement)
Tests statiques
Types de revue

62
Tests statiques
Types de revue

63
 Tests statiques
Facteurs de réussite
Les facteurs de réussite organisationnels pour les revues incluent :
• Chaque revue a des objectifs clairs, définis lors de la planification de la revue
• Le type de revue est choisi en fonction des objectifs
• Toutes les checklists utilisées couvrent les principaux risques et sont actualisées
• Les documents volumineux sont rédigés et révisés en petits morceaux
• Les participants ont suffisamment de temps pour préparer
• Le management appuie le processus de revue
Les facteurs de succès liés aux participants aux revues sont les suivants :
• Le choix des bonnes personnes contribue à l'atteinte des objectifs de la revue
• Les participants consacrent suffisamment de temps et d'attention aux détails
• Le résultat ne sera pas utilisé pour l'évaluation des participants
• Les participants évitent le langage corporel
• Une formation adéquate est fournie 64
Questions de révision

65
4
Techniques
de test
 Techniques de test
Termes : technique de test de boîte-noire, analyse des valeurs limites, test basé sur les check-lists, couverture, couverture des décisions,
test de tables de décision, estimation d’erreur, partitions d'équivalence, technique de test basée sur l'expérience, test exploratoire, test
des transitions d'état, couverture des instructions, technique de test, test des cas d'utilisation, technique de test de boîte-blanche.

1. Catégories de techniques de test

2. Techniques de test boîte-noire
3. Techniques de test boîte-blanche
4. Techniques de test basées sur l'expérience

67
 Choix de techniques de test
• Type de composant ou de système
• Complexité du composant ou des systèmes
• Normes réglementaires • Exigences client ou contractuelles
• Niveaux de risque • Types de risques
• Objectifs du test
• Documentation disponible
• Connaissances et compétences des testeurs
• Outils disponibles
• Temps et budget
• Modèle de cycle de vie du développement logiciel • Utilisation prévue du logiciel
• Expérience antérieure de l'utilisation des techniques de test sur le composant ou le système à tester
• Types de défauts attendus dans le composant ou le système 68
 Choix de techniques de test
Certaines techniques sont plus applicables à certaines situations et à certains niveaux de test ;
d'autres sont applicables à tous les niveaux de test.

Lors de la création de cas de test, les testeurs utilisent généralement une combinaison de techniques
de test pour obtenir les meilleurs résultats de l'effort de test.

L'utilisation des techniques de test dans les activités d’analyse des tests, de conception des tests et
d’implémentation des tests peut varier de très informel (peu ou pas de documentation) à très formel.
Le niveau de formalité approprié dépend du contexte des tests, y compris la maturité des processus
de test et de développement, les contraintes de temps, les exigences de sûreté ou réglementaires, les
connaissances et les compétences des personnes impliquées et le modèle de cycle de vie du
développement logiciel suivi.
69
 Catégories de techniques de test
Les techniques de test de boîte-noire (aussi appelées techniques comportementales ou techniques
basées sur le comportement) :
• sont basées sur une analyse de la base de test appropriée (exp spécifications, cas d'utilisation)
• sont applicables aux tests fonctionnels et non-fonctionnels.
• se concentrent sur les entrées et sorties de l'objet de test sans référence à sa structure interne.
Les techniques de test de boite blanche (aussi appelées techniques structurelles ou techniques
basées sur la structure) :
• sont basées sur une analyse de l'architecture, de la conception détaillée, de la structure
interne ou du code de l'objet de test.
• se concentrent sur la structure et le traitement à l'intérieur de l'objet de test.
Les techniques de test basées sur l'expérience tirent parti de l'expérience des développeurs, des
testeurs et des utilisateurs pour concevoir, implémenter et exécuter des tests.
Ces techniques sont souvent combinées à des techniques de test boîte-noire et boite blanche. 70
 Techniques de test boîte-noire
Partitions d'équivalence

Classe d’équivalence : Dans le cadre des tests fonctionnels, une classe d’équivalence est un
ensemble de valeurs pour lesquelles on ne peut distinguer le comportement du logiciel.
Couverture : nombre de partitions d'équivalence testées par au moins une valeur, divisé par le
nombre total de partitions d'équivalence identifiées.

EXP: le champs âge prend des valeurs entre 20 et 50 ans.

92
 Techniques de test boîte-noire
Analyse des valeurs limites
Le comportement aux limites des partitions d'équivalence est plus susceptible d'être incorrect que le
comportement à l'intérieur des partitions.

EXP: Deux valeurs limites

le champs âge prend des valeurs entre 20 et 50 ans.

EXP: Trois valeurs limites

93
 Techniques de test boîte-noire
Test de tables de décision
Les techniques de test combinatoire sont utiles pour tester la mise en œuvre des exigences du
système qui spécifient comment différentes combinaisons de conditions donnent des résultats
différents.
EXP :
* les véhicules diesel de 10 ans ou plus
se voient attribués un malus de 5%.
* les véhicules diesel de moins de 10 ans
se voient attribués un malus de 2%.
* les véhicules essence se voient attribués
un malus de 3%.
conditions :
C1 : diesel D1 : 5%
C2 : essence D2 : 2%
C3 : 10 ans ou plus D3 : 3%
94
 Techniques de test boîte-noire
Test de transitions d'état
Un diagramme de transitions d'état montre les états possibles du logiciel, ainsi que la façon dont le
logiciel entre, sort et évolue entre ces états.

95
 Techniques de test boîte-noire
Table de transitions d'état
Un tableau de transition d'état montre toutes les transitions valides et les transitions potentiellement
invalides entre les états, ainsi que les événements, les conditions de garde et les actions résultantes
pour les transitions valides. Les diagrammes de transition d'états ne montrent normalement que les
transitions valides et excluent les transitions invalides.

Signer contrat Signer contrat de

Etat actuel Dispute Décès
de mariage divorce

Célibataire Marié na na na

Marié Séparé Veuf Divorcé

Divorcé Marié

Séparé Veuf Divorcé

Veuf Marié

96
 Techniques de test boîte-noire
Test des cas d'utilisation
Les tests peuvent être dérivés de cas d'utilisation. Les cas d’utilisation sont une façon spécifique de
concevoir les interactions avec le logiciel pour représenter des exigences.
Step Description
1 A : Inserer la carte
Sénario principal 2 S : Valider la carte et demander PIN
A : Acteur
S : Système 3 A : Entrer PIN
4 S : Valider PIN
5 S : Permettre acces au compte
2a Carte non valide
S : message d'erreur et rejeter la carte

4a PIN non valide

Extension S : Message de demande de réessayer

4b PIN non valide 3 fois

S : Avaler carte

97
Questions de révision

98
 Techniques de test boîte-blanche
Test et couverture des instructions : Le test des instructions exerce les instructions exécutables dans le
code. La couverture est mesurée comme le nombre d'instructions exécutées par les tests, divisé par le
nombre total d'instructions exécutables dans l'objet de test, généralement exprimé en pourcentage.
Test et couverture des décisions : Le test des décisions exerce les décisions dans le code et teste le
code qui est exécuté sur la base des résultats des décisions.
La couverture est mesurée comme le nombre de résultats de décision exécutés par les tests, divisé par
le nombre total de résultats de décision dans l'objet de test, généralement exprimé en pourcentage.
Autres techniques basés sur la structure :
• Couverture de condition
• Couverture des conditions multiples

99
 Techniques de test basées sur l'expérience
Estimation d’erreur : c’est une technique utilisée pour anticiper les erreurs, les défauts et les défaillances,
sur la base des connaissances du testeur, y compris :
· Comment l'application a fonctionné antérieurement
· Quels types d'erreurs les développeurs ont tendance à faire
· Les défaillances qui se sont produites dans d'autres applications

Tests exploratoires : Dans les tests exploratoires, des tests informels (non prédéfinis) sont conçus,
exécutés, enregistrés et évalués dynamiquement pendant l'exécution des tests.
Utilisations : lorsqu'il y a peu de spécifications ou des spécifications inadéquates ou des contraintes de
temps importantes sur les tests.

Tests basés sur des checklists : les testeurs conçoivent, implémentent et exécutent des tests
pour couvrir les conditions de test figurant dans une checklist.
79
Utilisations : En l'absence de cas de tests détaillés.
Questions de révision

80
5
Gestion des
tests
 Gestion des tests
Termes : gestion de configuration, gestion des défauts, critères d'entrée, critères de sortie, risque produit, risque projet, risque, niveau de
risque, test basé sur les risques, approche de test, contrôle des tests, estimation des tests, Test Manager, pilotage des tests, plan de test,
planification des tests, rapport d'avancement des tests, stratégie de test, rapport de synthèse des tests, testeur.

1. Organisation des tests

2. Planification et estimation des tests
3. Pilotage et contrôle des tests
4. Gestion de configuration
5. Risques et tests
6. Gestion des défauts

10
3
Organisation des tests
Indépendance des tests

10
4
 Organisation des tests
Indépendance des tests :
Avantages Inconvénients
· Détecter des types de défaillances différents · Les testeurs peuvent être isolés de l'équipe de
par rapport aux développeurs en raison de développement : manque de collaboration, des
leurs connaissances propres, de leurs retards dans la communication des retours
approches techniques et de biais différents d'information à l'équipe de développement ou une
· Un testeur indépendant peut vérifier, relation conflictuelle avec l'équipe de développement
contester ou réfuter les hypothèses formulées · Les développeurs peuvent perdre le sens des
par les parties prenantes au cours de la responsabilités vis-à-vis de la qualité
spécification et de l'implémentation du système Les testeurs indépendants peuvent être considérés
comme un goulot d'étranglement ou être rendus
responsables des retards dans la sortie de la version
· Les testeurs indépendants peuvent ne pas disposer
84
de certaines informations importantes
 Tâches d’un Test Manager et d’un testeur
Les tâches habituelles du Test Manager Les tâches habituelles des testeurs
• Développer ou revoir une politique de test et une • Revoir et contribuer aux plans de test
stratégie de test pour l’organisation • Analyser, revoir et évaluer les exigences

• Planifier les activités de test • Identifier et documenter les conditions de test

Rédiger et mettre à jour le(s) plan(s) de test • Concevoir, configurer et vérifier le ou les environnement(s)

• Coordonner le(s) plan(s) de test de test

• Lancer l'analyse, la conception, l'implémentation et • Concevoir et implémenter les cas de test et les procédures

l'exécution des tests de test

• Préparer et fournir des rapports d'avancement des tests • Préparer et acquérir des données de test
• Aider la mise en place du système de gestion des • Créer le planning détaillé d'exécution des tests
défauts et à la gestion adéquate de la configuration des • Exécuter des tests, évaluer les résultats et documenter les
écarts par rapport aux résultats attendus
testware
• Utiliser les outils appropriés pour faciliter le processus de
• Introduire les métriques appropriées
• Décider de l'implémentation du ou des environnements test

de test • Automatiser les tests

• Développer les compétences et les carrières des • Évaluer les caractéristiques non-fonctionnelles
85
testeurs • Revoir des tests développés par d'autres
 Planification et estimation des tests
Objet et contenu d'un plan de test
Un plan de test décrit les activités de test pour des projets de développement et de maintenance.
La planification est influencée par la politique et la stratégie de test de l'organisation, les cycles de vie
du développement et les méthodes utilisées, l'étendue des tests, les objectifs, les risques, les
contraintes, la criticité, la testabilité et la disponibilité des ressources.
La planification des tests est une activité continue et s'effectue tout au long du cycle de vie du produit.

Les activités de planification des tests peuvent comprendre les éléments suivants, dont certains
peuvent être documentés dans un plan de test : périmètre, les objectifs et les risques, l'approche
générale des tests, les personnes et les autres ressources nécessaires, les métriques pour le pilotage
et le contrôle des tests, budgéter les activités de test, le niveau de détail et la structure de la
documentation des tests.
86
 Planification et estimation des tests
Stratégie de test et approche de test
Une stratégie de test fournit une description générale du processus de test, généralement au niveau du
produit ou de l'organisation. l'approche de test ajuste la stratégie de test pour un projet ou une version
particulière.
· Analytique : Le test basé sur les risques est un exemple d'approche analytique
· Basée sur des modèles : : Dans ce type de stratégie de test, les tests sont conçus à partir d'un modèle
d'un aspect requis du produit. Tels que q processus métier.
· Méthodique : utilisation d'un ensemble prédéfini de tests ou de conditions de test, tels qu'une
taxonomie de défaillances une liste des caractéristiques de qualité importantes, ou des normes
· Conforme à un processus (ou conforme à une norme) : basés sur des règles et normes externes,
· Dirigée (ou consultative) : Dicté par les recommandations, les conseils ou les instructions des parties
prenantes, des experts
· Anti-régressions : Eviter la régression au niveau des fonctionnalités existantes.
87
· Réactive : Réaction aux événements se produisant pendant l'exécution des tests, plutôt que préplanifié.
 Planification et estimation des tests
Les critères d'entrée :
· Disponibilité d'exigences testables, de User Stories et/ou de modèles (par exemple, lorsque l’on suit une
stratégie de test basée sur les modèles)
· Disponibilité d'éléments de test qui ont satisfait aux critères de sortie pour tous les niveaux de test
précédents
· Disponibilité de l'environnement de test
· Disponibilité des outils de test nécessaires
· Disponibilité des données de test et autres ressources nécessaires

10
9
 Planification et estimation des tests
Les critères de sortie :
· Les tests planifiés ont été exécutés
· Un niveau défini de couverture (par exemple, des exigences, des User Stories, des critères
d'acceptation, des risques, du code) a été atteint
· Le nombre de défauts non résolus est limité à ce qui a été défini
· Le nombre estimé de défauts restants est suffisamment faible
· Les niveaux évalués de fiabilité, de performance, d'utilisabilité, de sécurité et autres
caractéristiques qualité pertinentes sont suffisants

11
0
 Métriques utilisées pour les tests
Les métriques sont utilisées afin d'évaluer :
• Avancement par rapport au calendrier et au budget prévus
• Qualité actuelle de l'objet de test
• Pertinence de l`approche de test
• Efficacité des activités de test par rapport aux objectifs
Les métriques de test les plus courantes sont les suivantes :
• Pourcentage du temps de travail prévu réalisé pour la préparation des cas de test
• Pourcentage du travail prévu réalisé pour la préparation de l'environnement de test
• Exécution des cas de test
• Informations sur les défauts
• Couverture des exigences, des User Stories, …
• Degré d'achèvement des tâches, affectation et utilisation des ressources, et temps passé
• Coût des tests, y compris en comparaison avec le bénéfice apporté par la découverte des défauts
supplémentaires ou le coût par rapport au bénéfice de l'exécution de tests supplémentaires 90
 Rapports de test
Le but du rapport de test est de synthétiser et de communiquer les informations sur l'activité de test, à la fois
pendant et à la fin d'une activité de test (par exemple, un niveau de test).

Au cours du pilotage et du contrôle des tests, le Test Manager publie régulièrement des rapports
d'avancement de test pour les parties prenantes.

Le contenu d'un rapport de test variera en fonction du projet, des exigences organisationnelles et du cycle de
vie du développement logiciel.

Dans le développement Agile, les rapports d'avancement de test peuvent être incorporés dans les tableaux
de tâches, les récapitulatifs de défauts et les burndown charts.

En plus d'ajuster les rapports de test en fonction du contexte du projet, les rapports de test devraient aussi
être ajustés en fonction de l'audience du rapport. 91
 Rapports de test
Lorsque les critères de sortie sont atteints, le Test Manager fournit le rapport de synthèse de test.
Ce rapport fournit un résumé des tests réalisés, sur la base du dernier rapport d'avancement de test et de
toute autre information pertinente.
Les rapports d'avancement de test et les rapports de synthèse de test peuvent comprendre les éléments
suivants :
• Récapitulatif des tests réalisés
• Informations sur le déroulement de la période de test
• Ecarts par rapport au plan, y compris les écarts par rapport au calendrier
• Statut des tests et de la qualité du produit par rapport aux critères de sortie ou à la définition du terminé
• Facteurs ayant bloqué ou bloquant l’avancement
• Métriques sur les défauts, les cas de test, la couverture de test, la l’avancement de l'activité et la
consommation de ressources. (p. ex., tel que décrit au point 5.3.1)
• Risques résiduels
• Produits d'activités de test réutilisables 92
 Planification et estimation des tests
Calendrier d'exécution des tests

Suites de test : les différents cas de test et procédures de test produits et assemblés

Calendrier d'exécution des tests : définit l'ordre dans lequel , les suites de test doivent être exécutées.
Le calendrier d'exécution des tests devrait tenir compte de : l'ordre de priorité, les dépendances, les
tests de confirmation, les tests de régression et la séquence la plus efficace pour exécuter les tests.
Les cas de test devraient être exécutés en fonction de leur niveau de priorité ( en respectant les
dépendances ).

Les tests de confirmation et de régression doivent également être priorisés, en fonction de

l'importance d'une remontée d'information rapide sur les changements réalisés, mais là encore, des
dépendances peuvent s'appliquer.
93
 Planification et estimation des tests
Facteurs influençant l'effort de test
Caractéristiques du produit
· Les risques associés au produit / La qualité des bases de test / La taille du produit / La complexité
du domaine métier du produit / Les exigences en matière de conformité juridique et réglementaire
· Les exigences relatives aux caractéristiques de qualité (p. ex., sécurité, fiabilité)
· Le niveau de détail requis pour la documentation des tests
Caractéristiques du processus de développement
· La stabilité et la maturité de l'organisation / Le modèle de développement utilisé / L'approche de test
· Les outils utilisés /Le processus de test / La pression des délais
Caractéristiques liées aux personnes
· Les compétences et l'expérience des personnes impliquées / La cohésion et le leadership de
l'équipe
Résultats des tests
94
· Le nombre et la sévérité des défauts trouvés / La quantité nécessaire de travail à refaire
 Pilotage et contrôle des tests
Techniques d'estimation des tests

Il existe un certain nombre de techniques d'estimation utilisées pour déterminer l'effort requis pour des
tests adéquats. Deux des techniques les plus couramment utilisées sont les suivantes :
· La technique basée sur les métriques : estimer l'effort de test sur la base de métriques d'anciens
projets similaires ou sur la base de valeurs représentatives
· La technique basée sur l'expertise : estimation de l'effort de test sur la base de l'expérience des
responsables des tâches de test ou par des experts

➢ Les burndown charts sont des exemples d'une approche basée sur les métriques (Pour les développements agile).
➢ Le planning poker est un exemple d'approche basée sur l'expertise. (Pour les développements agile).
➢ La technique d'estimation Wideband Delphi est un exemple d'approche basée sur l'expertise
(Dans les projets séquentiels)

11
6
Questions de révision

11
7
 Gestion de configuration
Le but de la gestion de la configuration est d'établir et de maintenir l'intégrité du composant ou du
système, du testware et de leurs relations mutuelles tout au long du cycle de vie du projet et du produit.
Pour supporter correctement les tests, la gestion de la configuration peut assurer ce qui suit :
➢ Tous les éléments de test sont identifiés de façon unique, versionnées, suivis pour les
changements et reliés les uns aux autres
➢ Tous les éléments du testware sont identifiés de manière unique, versionnées, suivis pour les
changements, liés les uns aux autres et liés aux versions des éléments de test afin que la
traçabilité puisse être maintenue tout au long du processus de test
➢ Tous les documents et logiciels identifiés sont référencés sans ambiguïté dans la documentation
de test
Au cours de la planification des tests, les procédures de gestion de la configuration et l'infrastructure
11
8
(outils) devraient être identifiées et implémentées.
 Risques et tests
Le risque implique la possibilité d'un événement futur qui a des conséquences négatives. Le niveau
de risque est déterminé par la probabilité de l'événement et son impact (le préjudice).

Risque = Probabilité d’occurrence * Impact

Le risque produit implique la possibilité qu'un produit d’activités puisse ne pas satisfaire les besoins
de ses utilisateurs et/ou parties prenantes.
Lorsque les risques produit sont associés à des caractéristiques de qualité spécifiques d’un
produit/systéme les risques produit sont également appelés risques qualité.

Le risque projet implique des situations qui, si elles se produisent, peuvent avoir un effet négatif sur
11
la capacité d'un projet à atteindre ses objectifs. 9
 Risques et tests
Dans une approche basée sur les risques, les résultats de l'analyse du risque produit sont utilisés
pour :
• Déterminer les techniques de test à utiliser
• Déterminer les niveaux et les types spécifiques de tests à effectuer
• Déterminer le volume des tests à réaliser
• Prioriser les tests afin de trouver les défauts critiques le plus tôt possible
• Déterminer si des activités en complément des tests pourraient être utilisées pour réduire
les risques Les activités de gestion des risques fournissent une approche méthodique pour :
• Analyser (et réévaluer régulièrement) ce qui peut mal se passer (risques)
• Déterminer quels risques sont importants à gérer
• Mettre en œuvre des mesures pour atténuer ces risques
• Établir des plans de contingence pour faire face aux risques si ceux-ci devenaient des
événements effectifs 99
 Gestion des défauts
Tout défaut identifié doit faire l'objet d'une analyse et faire l'objet d'un suivi depuis sa découverte et sa
classification jusqu'à sa résolution (p. ex. correction des défauts et tests de confirmation de la solution
réussi, report à une version ultérieure, acceptation en tant que limitation permanente du produit, etc.).

Afin de gérer tous les défauts jusqu'à la résolution, une organisation devrait définir un processus de
gestion des défauts qui comprend un workflow et des règles de classification. Ce processus doit être
approuvé avec tous ceux qui participent à la gestion des défauts, y compris les concepteurs, les
développeurs, les testeurs et les Product Owners.

Dans certaines organisations, l'enregistrement et le suivi des défauts peuvent être très informels.

100
 Gestion des défauts
Un rapport de défaut comprend généralement les éléments suivants :
· Un identifiant
· Un titre et un bref résumé du défaut signalé
· La date du rapport de défaut, l'organisation émettrice et l'auteur
· L'identification de l'élément de test et de l'environnement
· La ou les phases du cycle de développement au cours desquelles le défaut a été observé
· Une description du défaut et L'historique des modifications
· La portée ou le degré d'impact (sévérité)
· Urgence/priorité de la correction
· L'état du rapport de défaut
· Les conclusions, recommandations et approbations
· Les enjeux généraux, tels que les autres domaines qui peuvent être affectés par un changement
101

· Les références, y compris le cas de test qui a révélé le problème

Questions de révision

102
6 Outils de
support aux
tests
 Outils de support aux tests
o Termes : test piloté par les données, test piloté par les mots-clés, outil de test de performance, automatisation des tests, outil
d'exécution des tests, outil de gestion des tests.

1. Introduction aux outils de test

2. Utilisation efficace des outils

125
 Outils de support aux tests
Classification des outils de test
Les outils de test peuvent avoir une ou plusieurs des finalités suivantes en fonction du contexte :

· Améliorer l'efficacité des activités de test en automatisant des tâches répétitives ou des tâches
qui nécessitent des ressources importantes lorsqu'elles sont effectuées manuellement
· Améliorer l'efficacité des activités de test en assistant les activités de test manuelles tout au long
du processus de test
· Améliorer la qualité des activités de test en permettant des tests plus cohérents et un niveau plus
élevé de reproductibilité des défauts
· Automatiser les activités qui ne peuvent être exécutées manuellement
· Augmenter la fiabilité des tests

126
 Introduction aux outils de test
Outils pour la gestion des tests et du testware

-- Harnais de test : Environnement comprenant les bouchons et les pilotes nécessaires pour exécuter un test. 106
-- L’effet de sonde : La conséquence de l'utilisation d'outils intrusifs
 Outils de support aux tests
Bénéfices de l'automatisation des tests

Les bénéfices potentiels de l'utilisation d'outils d'aide à l'exécution des tests incluent :

▪ Réduction du travail manuel répétitif

▪ Plus grande cohérence
▪ Évaluation plus objective
▪ Accès facilité à l'information sur les tests

128
 Outils de support aux tests
Risques de l'automatisation des tests

Les risques potentiels de l'utilisation d'outils en support aux tests incluent :

▪ Les attentes irréalistes à l'égard de l'outil

▪ Sous-estimation : du temps, du coût, de l'effort pour l'introduction initiale d'un outil..
▪ Il est possible que l'on se repose trop sur l’outil
▪ Le fournisseur peut apporter une réponse médiocre pour le support, les mises à niveau et les
corrections de défauts
▪ Un projet open source ou commercial peut être interrompu
▪ Une nouvelle plate-forme ou technologie peut ne pas être prise en charge par l'outil
▪ Il se peut qu'il n'y ait pas de propriété claire de l'outil
129
 Outils de support aux tests
Outils d'exécution des tests et de gestion des tests

Les outils d'exécution des tests : exécutent des objets de test à l'aide de scripts de test automatisés. Ce
type d'outil nécessite souvent des efforts importants pour obtenir des bénéfices significatifs.
❖ Le script capturé
❖ Approche de test piloté par les données
❖ Approche de test par mots-clés
❖ Les outils de Model-Based Testing (MBT)
Les outils de gestion des tests : doivent souvent s'interfacer avec d'autres outils ou feuilles de calcul pour
diverses raisons, telles que :
· Produire de l'information
· Maintenir une traçabilité cohérente des exigences
· Etablir un lien avec les informations de version de l'objet de test dans l'outil de gestion de configuration 109
 Outils de support aux tests
Utilisation efficace des outils

Principes de base pour la sélection des outils :

▪ Évaluation de la maturité de l'organisation, de ses forces et de ses faiblesses
▪ Évaluation de l'outil par rapport à des exigences précises et à des critères objectifs
▪ Identification des besoins internes pour le coaching et le soutien dans l'utilisation de l'outil
▪ Prise en compte des avantages et des inconvénients des différents modèles de licence (p. ex.,
commercial ou open source)
▪ Estimation d'un rapport coût-bénéfice basé sur une analyse de rentabilité concrète (si nécessaire)
Une preuve de concept (POC – Proof-of-Concept) devrait être effectuée pour déterminer si l'outil
fonctionne efficacement avec le logiciel à tester et au sein de l'infrastructure (ou identifier les
changements nécessaires)

131
 Outils de support aux tests
Projets pilotes pour d'un outil dans une organisation
l'introduction de l'outil sélectionné dans une organisation commence généralement par un projet pilote,
dont les objectifs sont les suivants :
▪ Acquérir une connaissance approfondie de l'outil, comprendre ses forces et ses faiblesses
▪ Évaluer la façon dont l'outil s'intègre aux processus et pratiques existants et déterminer ce qu'il
faudrait changer
▪ Décider des méthodes standard d'utilisation, de gestion, de sauvegarde et de maintenance de
l'outil et des actifs de test
▪ Évaluer si les bénéfices seront obtenus à un coût raisonnable.
▪ Comprendre les métriques que vous souhaitez voir recueillies et rapportées par l'outil, et configurer
l'outil pour s'assurer que ces métriques peuvent être recueillies et rapportées.

132
 Outils de support aux tests
Facteurs de succès pour les outils

▪ Déployer l'outil au reste de l'organisation de façon incrémentale

▪ Adapter et améliorer les processus en fonction de l'utilisation de l'outil
▪ Apporter de la formation, de l'encadrement et du conseil aux utilisateurs d'outils
▪ Définir des recommandations d’usage de l'outil (p. ex. normes internes pour l'automatisation)
▪ Mettre en place un moyen de collecte d'informations sur l'utilisation réelle de l'outil
▪ Suivre l'utilisation de l'outil et ses bénéfices
▪ Accompagner les utilisateurs d'un outil donné
▪ Recueillir les leçons tirées de l'expérience de tous les utilisateurs

133
Questions de révision

134
Merci !!
135