Maaret Pyhäjärvi is feedback fairy with a day job at F-Secure, where she works as Engineering Manager. She identifies as empirical technologist, tester and programmer, catalyst for improvement, author and speaker, and community facilitator and conference organizer. She was awarded as Most Influential Agile Testing Professional Person 2016 and has spoken at event in 24 countries delivering close to 400 sessions. With 25 years as exploratory tester before stepping into a role to manage developers, she crafts her engineering manager job into being a mix of leading a team of 12 and doing hands-on testing. She is a serial volunteer and organizing powerhouse contributing to European Testing Conference and Speak Easy, as well as Finnish non-profit scene. She blogs regularly at http://visible-quality.blogspot.fi, posts articles on Medium and Ministry of Testing the Testing Planet, and is author of two LeanPub books: Mob Programming Guidebook and Exploratory Testing.
As a tester, I don’t break your code, I break your *illusions* about your code. My work centers around finding the model you’re missing out on, to discover what you don’t know you don’t know, or things you know but have forgotten. I focus on identifying theories that don’t hold true in a world that is empirical. I break illusions so that with the information we have available together, we build systems worth using for various stakeholders.
This talk gives you a perspective into how a tester models an application domain through using software systems as their external imagination. We look through examples of illusions that need to be broken and skills you need to break them.
Illusions come in many forms. Illusions may be about the code doing what it’s supposed to; about the product doing what it would need to; about your process is able to deliver with change in mind; people having the skills to deliver well and about the business growing with uninformed risks on the product and the business model around it.
Testing is not just the technical checks but more relevantly it’s about discovering information about threats to value you’re trying to create. If you have little concern for the domain understanding, you are likely not doing a brilliant job at testing. Assume less, research more. See things others don't.