LES FONDAMENTAUX

DE TEST
By Dr. Imèn Khanchouch
C’est quoi un test?

■ « Le test est une technique de contrôle consistant à s'assurer, au moyen de son

exécution, que le comportement d'un programme est conforme à des données
préétablies » A.F.C.I.Q : Association Française pour le Contrôle Industriel et la Qualité.

■ Tester c’est réaliser l’exécution du programme pour y trouver des défauts et non pas
pour démontrer que le programme ne contient plus d’erreurs.

■ Les tests logiciel garantissent la qualité du logiciel en terme de fiabilité et de

performance, et le gain en temps et en argent et évite de nombreux problèmes qui
peuvent mettre fin à la vie d’un logiciel.

2
Crise du logiciel

■ Historiquement, il y a eu une prise de conscience dans les années 70, appelée la crise
du logiciel, du à un tournant décisif : c’est à cette époque que le coût de construction du
logiciel est devenu plus important que celui de la construction du matériel.
■ Certains projets n’aboutissent jamais et d’autres aboutissent avec des retards
importants.
Exemple 1 : Dans les années 60, OS-360 d’IBM fut livré en retard, il nécessitait plus de
mémoire que prévu, son prix de revient dépassait beaucoup les estimations, et ses
premières versions comportaient des erreurs.
Exemple 2 : En juin 1996, 37 sec après le décollage, la fusée Ariane 501 (prototype de la
version Ariane 5) fut détruite par une explosion : crash de la fusée  Le logiciel n’était pas
fiable.

3
Pourquoi tester ?

■ Le logiciel est de plus en plus complexe et critique!

■ Le zéro défaut n’existe pas en matière de logiciel!
■ Si un logiciel ne fonctionne pas correctement -> Perte du temps, perte d’argent,
entacher la réputation de l’entreprise.
■ Evaluer et contribuer à la qualité du logiciel
■ Réduit le risque de défaillance des logiciels.

4
ISTQB (International Software Testing
Qualifications Board)

5
Assurance Qualité (QA)

■ Permet de mettre en œuvre un ensemble de dispositions qui vont être prises tout au
long des différentes phases du cycle de vie d’un logiciel, pour accroître les chances
d’obtenir un logiciel qui correspond à ses objectifs (son cahier de charges).

■ La définition et la mise en place des activités de Test ne sont qu’un sous ensemble
des activités de l’Assurance Qualité, et le test aura pour but de minimiser les
chances d’apparition d’une anomalie lors de l’utilisation du logiciel.

6
Objectifs des tests

■ Evaluer les produits d’activités tels que les exigences, les user stories, la conception
et le code.
■ Vérifier si toutes les exigences spécifiées ont été satisfaites.
■ Construire la confiance dans le niveau de qualité de l’objet de test
■ Prévenir des défauts (code)
■ Trouver des défaillances et des défauts (logiciel)
■ Réduire le niveau de risque.
■ Se conformer aux exigences ou aux normes contractuelles, légales ou
réglementaires.

7
Une exigence doit être ?

■ Exprimée en une phrase simple

■ Utile
■ Traçable avec un numéro unique, historiser les modifs
■ Non ambiguë ; avoir qu’une seule interprétation
■ Cohérente ; ne pas contredire une autre exigence
■ Réalisable quant aux moyens mis en œuvre pour le projet.

8
Test et débogage

■ Le débogage : l’activité de développement qui détecte, analyse et corrige les

défauts.
■ Le test de confirmation vérifie si les corrections apportées ont résolu les défauts.
■ Les testeurs sont responsables du test initial et du test de confirmation.
■ Les développeurs se chargent du débogage et du test des composants.

9
Erreurs, défauts et défaillances

1. Erreur : Quelles sont les raisons des erreurs ?

■ La contrainte du temps
■ L’inexpérience ou le manque de compétence des participants au projet
■ Une mauvaise communication entre les membres du projet
■ La complexité du code ou de la conception.
■ Des technologies nouvelles peu connues.

10
Erreurs, défauts et défaillances
2. Un défaut : survient lorsque l’être humain se trompe par mégarde, appelée une erreur,
en accomplissant certaines activités logicielles. (IEEE 729)

3. Une défaillance : est la modification d’un comportement requis d’un système (IEEE 729)

11
Erreurs, défauts et défaillances

■ Faux positif (pas un bug ou bug invalide)

o Erreur d’exécution des tests
o Données de test erronées
o Problèmes d’environnement; mal configuré
■ Faux négatif
o Les tests qui ne détectent pas les défauts qu’ils auraient du détecter.

 Le testeur risque de perdre sa réputation si le taux de faux négatif est inadmissible.

12
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 défauts peuvent être analysés pour identifier leurs causes racines, afin de
réduire l'apparition de défauts similaires à l'avenir. En se concentrant sur les causes
racines les plus importantes, l'analyse des causes racines peut conduire à des
améliorations de processus qui préviennent l'introduction d'un nombre important de
défauts futurs.

13
Défauts, causes racines et effets

■ Supposons que des paiements d'intérêts incorrects, dus à une seule ligne de code
incorrecte, se traduisent par les plaintes des clients. Le code défectueux a été écrit pour une
User Story qui était ambiguë, en raison de la mauvaise compréhension par le Product Owner
de la façon de calculer les intérêts.

 Effet : les plaintes des clients

 Défaut : La ligne de calcul incorrecte dans le code
 Défaillance : Les paiements d'intérêts incorrects
 La cause racine du défaut initial : le manque de connaissance de la part du Product Owner

14
Les 7 principes de test
1. Les tests montrent 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
3. Tester tôt économise du temps et de l’argent (permet de réduire ou d'éliminer des
changements coûteux )
4. Regroupement des défauts
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)
6. Les tests dépendent du contexte
7. L’illusion de l’absence d’erreurs -> 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

15
Le processus de test

Clôture des
Analyse Conception Implémentation Exécution
tests

Planification, Suivi et contrôle des tests

16
Les activités du processus des tests
Matrice de traçabilité bidirectionnelle

Analyse Conception
Exigences
1. Réviser la base 4. Concevoir les
de test (Examiner cas de test
la spec)

2. Identifier et Conditions
prioriser les 5. Identifier les de test
conditions et cas données de test
de test
6. Concevoir
3. Evaluer la
l’environnement Cas de test
testabilité
de test

17
Les activités du processus des tests

Implémentation Exécution
4. Vérifier la
1. Développer les disponibilité des
suites et cas de test environnements
de test

2. Construire 5. Mettre à jour la

l’environnement matrice de traçabilité
de test bidirectionnelle

3. Préparer les 6. Exécuter les cas

jeux de données de test

18
Les activités du processus des tests
Clôture

1. Vérifier la clôture 3. Finir et archiver le 5. Analyser les

des rapports de testware leçons apprises
défauts

2. Créer un rapport 4. Remettre le testware 6. Améliorer la

de synthèse de test aux équipes de maturité du
maintenance processus de test

19
Les activités du processus des tests
Planification Suivi et contrôle

1. Définir les objectifs 4. Vérifier les résultats

de test et logs des tests

2. Elaborer le plan de 5. Evaluer le niveau de

test la qualité

3. Coordonner le plan 6. Déterminer la

de test nécessité d’autres tests

20
Les activités du processus des tests
Activité de test Produits livrés
Planification des tests 1. Plan du test
2. Définition du « terminé » Done en Agile
Pilotage et contrôle 1. Rapport d’avancement des tests
2. Rapport de synthèse
3. Rapport des résultats de test
Analyse 1. Conditions de test définies et priorisées
2. Liste des défauts découverts
Conception 1. Liste des cas de test
2. Liste des données de test nécessaires
3. Liste des environnements de test nécessaires
Implémentation 1. Les suites de test
2. Un calendrier d’exécution des tests
3. Liste des données de test créées
4. Etat de disponibilité des environnements de test
21
Les activités du processus des tests

Exécution 1. Statut de chaque cas de test

2. Rapport des défauts
Clôture 1. Rapport de synthèse des tests
2. Mesures à prendre pour améliorer le projet
3. Demandes de changement du backlog

22
La psychologie des tests
■ Un certain degré d’indépendance est souvent plus efficace pour détecter des défauts:
o Tests conçus par d’autre(s) personne(s) de la même équipe.
o Tests conçus par une ou des personnes d’une équipe différente au sein de la même
entreprise.
o Tests conçus par une ou des personnes d’une société différente (ex: sous-traitance ou
certification par un organisme externe)

■ Les tests sont souvent vus comme une activité destructive!

■ Les testeurs et le responsable des tests ont besoin de bonnes compétences relationnelles
pour communiquer les informations factuelles sur les défauts et les risques d’une manière
constructive.

23
La psychologie des tests

■ Comment améliorer la communication et les relations entre les testeurs et leurs

interlocuteurs ?
1. Commencer par une collaboration plutôt que par des conflits.
2. Rappeler à chacun l’objectif commun de systèmes de meilleure qualité.
3. Communiquer les bugs sur le produit de façon neutre et factuelle sans critiquer la
personne responsable.
4. Essayer de comprendre ce que ressent une autre personne et pourquoi elle a réagit
comme elle le fait.

24
Etat d’esprit Testeur vs Développeur

Développeur Testeur
Construire Curiosité
Optimisme Pessimisme professionnel
Concevoir Œil critique
Tester son propre code Attention aux détails
Difficile de trouver des erreurs dans son Bonne communication
propre travail

25
Merci 

26