3. • Ingénieur civil physicien de
l’ULiège
• Chercheur à l’ULiège
• Expert audio chez IPTrade
• Test manager (responsable du
“QTAC”) chez IPTrade
• Test & Interop Manager chez
British Telecom
Brice Mattivi
4. Plan de la
présentation
• Le testing
• La mentalité du testeur
• Techniques de tests (White Box, Black Box,
exploratory testing, unit testing…)
• Les outils du testeur
• Testing automatique vs Testing manuel
• Organisation
• Le mot de la fin
6. Que sont les
tests logiciels
Les tests logiciels sont un moyen
1. D'évaluer la qualité du logiciel
2. De réduire le risque de défaillance
de ce logiciel en cours de
fonctionnement
7. Objectifs
habituels des
tests
• Vérifier si toutes les exigences
spécifiées ont été satisfaites
• Prévenir des défauts
• Trouver des défaillances et défauts
• Obtenir une idée claire de la qualité de
l’objet testé
• Réduire le niveau de risque d'une
qualité logicielle inadéquate (p. ex. des
défaillances non détectées auparavant
se produisant en opération)
• Se conformer aux exigences ou aux
normes contractuelles, légales ou de
sécurité
8. Activités habituelles des équipes de tests
Analyse de spécifications
(Logical Test Plan)
Écriture de Tests Plan
9. Activités habituelles des équipes de tests
Tests fonctionnels
Tests d’intégration
Tests d’Interopérabilité
Tests de charge et performance
10. Activités habituelles des équipes de tests
Programmation/scripting
de tests automatiques
(fonctionnels/BB, les tests unitaires
sont faits par les programmeurs)
Revalidation de bugs
11. Vrai ou
faux?
❑ Testing et debugging sont synonymes
❑ Il est préférable de lancer les activités
de tests lorsque les activités de coding
sont terminées
❑ Le testing est parfois dénommé QA
❑ Un testeur professionnel est un
programmeur frustré ou un
développeur incapable de coder
❑ Il est préférable que le testeur ne
connaisse pas préalablement le
système, de telle sorte qu’il teste avec
l’esprit vierge.
F
F
V
F
V et F
12. Debugging vs
Testing
Les tests mettent en évidence des
défaillances qui sont dues à des défauts
dans le code.
Le debugging est l'activité de
développement qui trouve, analyse et
corrige les défauts.
14. QA vs QC
• QA: Quality Assurance, s’occupe des
procédures.
• Le testing: Contrôle Qualité (QC), ne
vérifie pas les procédures, seulement
le résultat final
QA = QC: Abus de langage courant
15. • Une profession relativement récente
(ISTQB créé en 2002)
• Le testeur aime découvrir de nouvelles
choses et trouver la faille.
• Un développeur aime trouver des
solutions et concevoir/construire son code.
Testeur: un métier à part entière
16. Les rôles dans
une équipe de
testing
• Test manager
• Analyste
• Testeur
• Développeur (tests autos ou tools)
20. Peu de
vocation de
départ pour la
profession de
testeur. Mais
quand on y
prend goût...
Pas de formation en Testing en Belgique
intégrée à un cursus
Mais le testeur dispose généralement
• D’un profond intérêt pour l’informatique,
la technologie et la logique
• D’une formation dans les domaines de
la techno (bachelier en informatique,
ingénieur…)
• De beaucoup de rigueur et d’une
profonde envie d’explorer et de
comprendre
Une certification (exemple ISTQB) est un
plus, mais généralement acquise “en
cours de route”
21. L’état d’esprit
du testeur
• Le pessimisme professionnel
• Le goût de l’exploration
• La fiabilité
• Il représente l’utilisateur final au sein du
R&D
22. Le pessimisme
professionnel
• Le testeur sait qu’il y a des problèmes et
les cherche
• La loi de Murphy est son guide
• Combien de bugs restent dans le
système? Encore au moins un!
23. Le goût de
l’exploration
• Connaissance du système = réduction
des faux positifs
• Système en perpétuelle evolution
• Exploratory testing
24. La fiabilité
Un bon testeur doit toujours vérifier
plusieurs fois ce qu’il avance, car:
• Il est le garant de l’évaluation de la
qualité au sein du R&D
• Sa crédibilité personnelle est en jeu
Métrique intéressante: pourcentage
d’invalide
25. La psychologie
• Testeur: trouver un bug = excellente
nouvelle
• Programmeur: avoir “codé” un bug =
très mauvaise nouvelle.
26. Le représentant
du client au
sein du R&D
• Doit penser comme le client
• Garant de l’expérience utilisateur
• Gestionnaire de la priorité des bugs
28. 7 principes
1. Les tests montrent la présence de
défauts, par leur absence
2. Les tests exhaustifs sont impossibles
3. Tester tôt économise du temps et de
l’argent
4. Regroupement des défauts
5. Paradoxe du pesticide
6. Les tests dépendent du contexte
7. L’absence d’erreurs est une illusion
30. White Box
Testing et tests
unitaires
• Basés sur les structures internes d’un
système.
• Généralement: tests effectués par les
programmeurs
• Exemple: tests unitaires où l’on identifie
les différents chemins d’exécution du
code.
31. Black Box
Testing
• Le black box testing consiste à tester
un code compilé en connaissant ses
spécifications
• Le black box testing n’a que faire des
mécaniques internes
• Exemples de techniques: partition,
valeurs limites, table de décision
32. Tests statiques
vs dynamiques
• Statiques: Inspection de code, de
documentation, de test plan, de
spécifications
• Dynamiques: Repose sur l’exécution du
code.
33. Le cas
particulier de
l’exploratory
testing
• Tests basés sur l’expérience du testeur
• Difficultés: consigné ce qui a été fait,
reproduire les scénarii fautifs
• Nécessite un testeur confirmé
35. Les tests de
non-régression
• Tests autos (tests unitaires, tests
fonctionnels)
• Tests manuels avec un bon config
management
36. Les “exit criteria”
• Répondent à la question: quand faut-il
arrêter la phase de tests
• Nécessaire, car on peut toujours trouver
de nouveaux bugs
• Permettent de caractériser le niveau de
qualité requis
37. Exemples
d’exit criteria
• Date de sortie de release (aaargh)
• Couverture des tests
• Nombre de bugs trouvés dans les
dernières x semaines
• Criticité des bugs trouvés à la fin d’une
campagne de tests
45. Quand
automatiser?
• Zone du système qui bouge peu (P1 des
tests de non-régression).
• Tests unitaires
• Tests de performance
• Tests de charge
46. Quand utiliser
des tests
manuels
• Nouvelles features
• Tests de régression “touchy”
• Partout où la flexibilité est importante
Paradoxe du pesticide: les tests
automatiques finissent par montrer de
moins en moins d’efficacité. L’humain
est plus flexible.
49. Développeurs/
Testeurs
• Au moins deux développeurs
• Un développeur ne joue jamais le rôle
de testeur pour son propre travail
• Le développeur teste bien entendu son
travail via les tests unitaires
54. Manager/Tester
+ Point de vue extérieur au
développement
+ Peu de risque de biais (quoique, pour le
CTO…)
- Manque de temps pour tester
- Risque de manque d’envie et/ou de
méthode pour la tâche.
55. Testeur au
sein d’une
équipe de
programmeurs
• Testeur = Un développeur pas comme
les autres (le gardien de but au foot)
• Peut dépendre du chef d’équipe de la
cellule de développement
• Peut aussi dépendre d’un test manager
et être détaché dans la cellule de
développement
56. CTO
Dev1 Dev2 Dev3 Tester
Team
Leader
1
Dev1.1 Dev1.2 Dev1.3
Tester
1
CTO
Test
Manag
er
Team
Leader
2
Dev2.1 Dev2.2 Dev2.3Tester
2
57. Testeur au
sein d’une
équipe de
programmeurs
+ Le testeur est intégré dans l’équipe et
perçu comme un allié.
+ Très bonne connaissance du produit
pour le testeur par “transpiration”
- Influence forte des développeurs
- Délicat à mettre en place pour de
grosses équipes
58. Une équipe de
test
indépendante
dans le dev
• Plusieurs testeurs en équipe sous la
direction d’un test manager
• Le test manager et d’autres
responsables de développement
(architecte, chefs d’équipe) dépendent
d’une même personne (typiquement, le
CTO)
60. Une équipe de
test
indépendante
intégrée au
dev
+ Bonne connaissance du produit pour les
testeurs
+ L’autorité commune peut highlighter le
fait que le test est important auprès des
équipes de dev
- Influence du CTO sur le test.
- L’équipe de test peut être perçue comme
un ennemi par les autres développeurs.
61. Une équipe de
test hors de la
structure de
dev
• L’équipe de test dépend d’un test
manager qui dépend d’un quality
manager
• Les testeurs peuvent travailler dans des
bâtiments séparés et/ou être des
consultants externes
63. Une équipe de
test hors de la
structure de
dev
+ Complète indépendance.
+ Vraie possibilité de “bloquer une release”
par exemple
- Mauvaise communication avec les
développeurs
- Cellule de test perçue comme un ennemi
ou un mal (non-) nécessaire
- Connaissance du produit plus difficile à
acquérir par les testeurs