Le rôle du testeur et le Blackbox testing
1 j'aime192 vues
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.
Le rôle du testeur et le Blackbox testing
- 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.
- 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
- 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
- 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
- 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)
- 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”