Le document traite du rôle crucial des testeurs dans le développement logiciel, en mettant en avant les différentes techniques et méthodologies de test, telles que le black box testing. Il discute également des compétences nécessaires pour devenir testeur, des environnements de travail, et des outils utilisés dans le processus de test. Enfin, il souligne l'importance de la qualité et de la collaboration entre développeurs et testeurs pour assurer un logiciel fiable.

1. Le role du testeur et le
black Box testing
Les héros méconnus du développement informatique
Par Brice Mattivi

2. À propos de moi…

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

5. Le Testing
Définition, différentes tâches et rôles liés au testing

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.

13. Quand tester?
V Model

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)

17. La mentalité du testeur

18. Comment
devient-on
testeur?

19. Souvent par
hasard

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

27. Techniques de tests

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

29. Tests
fonctionnels vs
non-fonctionnels
• Fonctionnels: Tester ce que le
système fait (les fonctionnalités)
• Non-Fonctionnels: Tester comment
le système se comporte:
Performance,usabilité,sécurité…

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é

34. Les régressions • Le cauchemar du testeur
• Le cauchemar du client

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

38. Les outils du testeur

39. Bug Tracking
system
• Jira
• Bugzilla
• Mantis
• …

40. Test
management
system
• Test Link
• Zephyr
• TestRail
• …

41. Continuous
integration
• Jenkins
• TeamCity
• Bamboo
• …

42. Automatic
Testing
• Selenium (Web)
• Squish (UI, QT)
• …

43. Testing manuel vs Testing automatique

44. Le Testing automatique • Avantages
• Inconvénients

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.

47. Organisation

48. Cinq types
d’organisation
• Développeurs/Testeurs
• Manager/Testeur
• Testeur au sein d’une équipe de Dev
• Équipe de Test semi-indépendante
• Équipe de Test indépendante

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

50. CTO
Dev1 Dev2
CTO
Dev1 Dev2

51. Développeurs/
Testeurs
+ Organisation facile à mettre en place
- Switch de mentalité nécessaire
- Risque de ne pas accorder aux tests
l’importance requise

52. Manager/Tester
• Le management s’assure de la qualité
du produit
• Le CTO, un Product Manager voire un
Project Manager prend le rôle

53. CTO
Dev1 Dev2

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)

59. Team
Leader
Dev1 Dev2 Dev3
CTO
Test
Manag
er
Dev4
Tester
1
Tester
2

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

62. Team
Leader
1
Dev1.1 Dev1.2 Dev1.3
CTO
Team
Leader
2
Dev2.1 Dev2.2 Dev2.3
Quality
Manag
er
Test
Manag
er
Tester
2
Tester
1
Tester
3

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

64. Le mot de la fin

65. Grâce aux testeurs professionnels,
les développeurs n’ont plus besoin
de tester leur code. V/F?

66. Faux

67. “La qualité est l’affaire
de tous”