Tests exploratoires : kézako ?
•
0 j'aime•62 vues
Talk pour introduire ce que sont les tests exploratoires. 2015.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Tests exploratoires : kézako ?
- 1. Tests exploratoires : Kézako ?
- 2. Tests exploratoires Que représente un Test ? Qui teste ?
- 4. Tests exploratoires Sur le papier c’est très bien Risque ? Tests aléatoires : pas sur la conformité
- 7. Tests exploratoires a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project
- 12. Tests exploratoires Comment faire un test d’exploration ?
- 13. Tests exploratoires Comment faire un test d’exploration ?
- 14. Tests exploratoires Exemple (efluid) J’explore la modification d’acteurs avec des attaques d’injections pour découvrir une faille de sécurité
- 15. Tests exploratoires A quoi ça sert ? Observation
- 16. Tests exploratoires A quoi ça sert ? 3+2 = 5 fuite mémoire ? problèmes de CPU ? faire n'importe quoi en BDD
- 17. Tests exploratoires Aide Collègues Tips • Imagine un article horrible sur ton logiciel • Ton pire cauchemar
- 18. Tests exploratoires Aide « Tours » par James Whittaker Business District • Guidebook Tour • Money Tour • FedEx Tour • … Tourist District • Collector’s Tour • SuperModel Tour • Scottish Pub Tour • … Seedy District • Saboteur • Antisocial Tour • Obsessive-Compulsive • … Historical District • Bad-Neighborhood • Museum Tour • Prior Version Tour • … Entertainment District • Supporting Actor Tour • Back Alley Tour • All-Nighter Tour • … Hotel District • Rained-Out Tour • Couch Potato Tour • …
- 19. Tests exploratoires Antisocial Tour Vous n’êtes pas comme les autres Design et execution du tour : • Je fais toujours l’opposé de ce que font les autres : j’appuie sur annuler au lieu de OK, sur retour au lieu de suivant, etc. • J’utilise des entrées invalides au lieu d’entrées valides • J’exécute la feature dans le mauvais ordre
- 20. Tests exploratoires Supermodel Tour Tout est sur l’apparence ! Design et execution du tour : • Choisir une feature • Vérifier scrupuleusement qu’elle respecte la charte graphique • Tous les textes sont justes (orthographe, grammaire et conjugaison) • Tout est aligné au pixel près • Tous les champs sont à la taille spécifiée au pixel près • Etc.
Notes de l'éditeur
- Un classe de TU ? Un recetteur qui clique pour tester une feature ? Offrez à votre petite sœur un téléphone portable, elle va appuyer partout sur tous les boutons : elle teste et c’est un vrai test. On parlera pas de qualité de code ou de couverture, ce qui importe c’est le produit fini
- Si je veux tester mon téléphone : Je vais vérifier qu’il est conforme à ce qu’on ma spécifié J’ai la spec, qqun l’a implémenté je vérifie la sortie ça c’est conforme Developpeur ce qu’on a en tête : je connais les entrées je vérifie la sortie : 3+2 = 5 content
- Sauf qu’on est sur des systèmes extrêmement complexes On est tous conscient ici que dès qu’on ajoute une fonctionnalité, qu’on refactore, qu’on change une ligne de code potentiellement on prend un risque: effets de bords, non prévu Tests aléatoires : pas sur la conformité car on peut la scripter, mais plutôt sur le risque
- On arrête de se dire qu’on maitrise tout et qu’on connait tous les entrants et tous les sortants On assume juste qu’on est dans un système trop complexe (la jungle) pour tout maitriser donc y’aura forcément des choses qu’on ne pourra pas tester de manière automatisée : comment on fait ? Comment on fait pour tester un cluster avec n fonctionnalités et que tout marche si on en rajoute une, on en enlève une, etc. Les tests exploratoires ça sert à ça. La c’est une métaphore, lara c’est le testeur et la jungle devant nous c’est le produit fini.
- Ceux qui ont inventé ce concept, qu’est-ce qu’ils considèrent comme testé : checké (TU/TI) + exploré.
- Si on prend la définition exacte (wiki) on voit des notions de personal freedom, responsabilité. On voit surtout les 4 mots : apprentissage, exécutions, résultats et interprétation
- Vous vous imaginez à la place de Lara avec votre machette dans la jungle : comment vous faites pour vous en sortir ? Vous n’allez pas explorer toutes la jungle pendant 2h, on fait un peu de design : on part du produit on dit par exemple je vais aller entre les 2 arbres du fond et je vais tout couper.
- 2ème phase, c’est la phase d’exécution Quand on part avec les TE on ne sait pas ce qu’on va faire, on a une idée on sait a peu près où on veut aller mais comment on va y arriver au moment où on s’assoit sur sa chaise on sait pas encore vraiment.
- Notion d’apprentissage : la première fois comme tous les explorateurs on se paume, donc on perd du temps. On teste des trucs qui sont pas importants. Les TE, si vous venez d’arriver sur un projet, c’est un très bon moyen de prendre en main le projet : vous partez sans apriori vous partez seulement avec le produit fini et vous essayez de le challenger : qu’est-ce qui se passe si je fais ça, qu’est-ce qui se passe si je fais ci. Au début on met beaucoup de temps et petit à petit on sait. Je pense qu’on connait les fragilités et ça peut guider.
- La dernière notion c’est la notion de direction : a chaque fois qu’on expérimente, on progresse on apprends et on se dirige de mieux en mieux et on est de plus en plus efficace.
- Le risque c’est de se perdre, et perdre des heures et des heures. Si on me donne un téléphone et que je dois le tester, je ne vais pas appuyer sur tous les boutons tout de suite et partir à l’arrache. Je vais finir par appuyer sur tous les boutons, mais je vais m’organiser. On « time-box », on prévoit des sessions de n heures, disons 2-3 par exemple et on ne dépasse pas cette fenêtre. Et surtout on prends des notes (reproduction, partage) !
- Pattern utilisé Explore : quelle partie je vais tester (une feature, un module, un webservice) With : avec quoi (un jeu de données, outils, techniques, configs, etc.) To discover : dire ce qu’on cherche (problème de sécurité, de perfs, de scalabilité, d’usabilité)
- Là y’a de quoi travailler au moins 2-3h. Faut que ce soit pas trop gros et pas trop précis.
- Arrêter de se concentrer sur le résultat mais vraiment sur le résultat et tout ce qu’il y a autour.
- Pourquoi parce que pour trouver des bugs vicieux, il fait être vicieux et c’est grâce aux tests exploratoires qu’on peut être vicieux.
- Comment savoir quoi explorer Brainstorming (pas trop délirant) Et on convertit en feuille de route
- Des tours ont été rédigés par James Whittaker testeur chez Microsoft pour donner des idées.