Je suis testeur logiciel indépendant à Lyon et surtout en remote.
Peut-on tester sans cahiers de recette ? Dans un environnement avec peu de spécifications fonctionnelles, comment faire de la non-régression ou trouver le cas un peu tordu qui va "casser" l'expérience utilisateur ? Cet atelier va vous apprendre à faire des sessions de test exploratoire efficaces.
Des problèmes avec des logiciels, on en a tous eu: dans les produits auxquels on participe au développement ou même dans ceux qu’on utilise au quotidien.
Lorsque c’est le tunnel d’achat qui est cassé pour les quelques utilisateurs ayant mis dans leur panier un produit particulier, c’est une perte de revenue et d’image, mais l’impact reste limité. Mais lorsqu’il devient possible de mettre dans son panier des quantités négatives de produit et que le client peut être crédité de la somme au lieu d’en être débité, cela peut vite couter très cher si le “truc” vient à se faire connaitre; et pour cela les réseaux sociaux se feront un plaisir d’être vos pires ennemis.
De plus vous pouvez faire confiance à la diversité du monde pour avoir l’originalité suffisante d’avoir des données relativement improbables aux conséquences pouvant être désastreuses pour votre business.
En allant de la personne recevant toutes les amendes de sa ville, au logiciel de reconnaissance faciale ayant des réactions racistes, au chômeur régulier sommé de rembourser une somme énorme par les services sociaux, au formulaire ne vous permettant pas de saisir votre situation, les logiciels ne sont pas toujours là pour nous faciliter la vie lorsqu’ils ont oublié des cas de figure particuliers.
Dans ce talk, je présenterai plusieurs exemples d’échecs logiciels qui ont eu des conséquences parfois étonnantes. Cela peut être dû à une maladresse, un oubli, un bug ou même une utilisation frauduleuse du système. Avec des exemples parfois drôles, parfois dramatiques voire choquants, vous verrez que la complexité de nos métiers n’est pas que dans la technique. Je parlerai aussi un peu des biais cognitifs qui font qu’involontairement on ne fait pas toujours les bonnes décisions, même si on s’est armé de la meilleure volonté du monde, et d’une quantité de travail énorme.
Finalement, pour pallier à cela, bien entendu il faut tester son produit, et pas seulement le produit développé mais aussi les idées et principes qui fondent celui-ci. Le contenu de ce talk peut donc potentiellement intéresser les responsables produits, les développeurs, les UX designers, les business analyst, les testeurs…
Testing is a craft, but it is also and for many foremost a job. A job you do day in day out, evolving with all the rituals every employee develops over time. These rituals, together with all sorts of other external factors (deadlines, pressure, etc.) often means that we don’t have a test strategy or that we are no longer reconsidering the strategies we set out from the start. Having the right strategy in testing is important to stay as efficient and effective as you can be.
Good stories last: They release emotions, they have their own life, they make you proud and they can help you inform and move others. This is why we embarked on our quest: the quest for the Ultimate Test Story! We set forth to scour the earth in search of testers. Testers with interesting experiences and crazy stories to tell, but not having the words to bring them to life. Our weapon of choice: Test Sphere. A deck of hundred cards that inspires and supports these testers to craft, temper and shape their raw experiences into strong, red-hot stories of power.
Twitter
LinkedIn
Blog
À propos
