Interview With Maaret Pyhäjärvi
Maaret is a feedback fairy with 25-years of experience on testing and everything around it. She has collected a few awards here and there, takes pride in someone having added her in Wikipedia, and considers speaking in tech conferences a hobby.
Her work is about transforming to better testing from within the teams. She writes public notes about things work brings her way on Twitter, and blogs about things inspired by work from her career.
She is a dedicated mom of two teenage kids she rarely speaks of outside her family unit, and a fierce defender of people in her circles of influence. She knows programmers can test and testers can code but may not always have the time, and that we all are better together with problems too big and relevant left for individuals.
You’ve done a lot to give back to the tech community with initiatives such as Tech Voices. What inspired you to get involved with this and what advice do you have for others hoping to pay it forward?
Personally I don’t think I am giving back to the tech community. I think I am drawing lessons from the tech community. The people who are not yet on stages as speakers, have invaluable practical experience of living the life in companies I am not at, and by spending time helping them package their knowledge – or appreciate it – I can also learn that for myself.
Getting started with speaking was one of those spite-driven improvements I have done over the years. I was working against crippling stage fright and I started speaking in spite of it. Since I needed the practice, I really threw myself into it and got the flow. Using that lesson then to help others to draw from their experiences felt like a natural continuum.
I was a community-learner first, and this is a continuation of the theme. I would think others want to learn effectively too, and it is only a plus when you can at same time support someone else to reach stages and contribute to the wider base of knowledge from those stages.
I see you are updating one of your books, Exploratory Testing and have added “contemporary” to the title – what do you mean by that? Has anything, in particular, changed in the testing landscape that you hope to address with your updates?
I have been following exploratory testing throughout my 25 years in testing, really doing pretty much only that. I have come to understand that all testing (the verb) is exploratory but not all testing (the noun) is. A lot of organizations have ideas about testing that don’t allow for exploratory testing. This has lead to people boxing exploratory testing into a technique that fits the organizations that don’t really understand it as an approach, and don’t know how to manage and lead such efforts.
Contemporary exploratory testing is my way of both returning to roots of the idea (way smart product company testers did testing) and updating the original idea with contemporary facts, such as technologies (webUIs, APIs to mention a few) allowing for effective documenting as automation while exploring, and thus allowing us to revisit the reasons we still think there are “manual” and “automated” forms of testing. I prefer to think myself that there are attended and unattended forms, all in the frame of contemporary exploratory testing and we care for results.
You’ve given over 400 talks over the course of your career. Compared to your first 2 years of giving talks; what do you differently in your talks now?
In first two years, I read a book and talked enthusiastically about stuff that resonated with my work experience. I thought what smart people writing books say is more relevant than anything I could say. Now, I talk from my experiences.
I had more text in my slides back then. I kind of used them as notes of what I wanted to say. Now I have very few words, and I know people don’t get to listen to me if they are reading my slides.
The third thing that is clearly different is that I now talk about testing on some of my talks. Back in the days I talked around testing. Like the organization, the processes but not really about test design and test execution, or strategies with ideas guiding test design and execution. I was worried someone would tell me I don’t know how to test, and chose subjects that were not risking being found out for fraud.
You’ve mentored several speakers at the start of their public speaking journey. What advice do you have for new speakers or people thinking about speaking at conferences?
You should do it. It helps you sort out your thoughts. It invites people who are interested in same things you are come and talk with you. It creates a community you can learn with. It positions you as an expert, which in turn can have a positive impact on career growth. The skills you learn will help you discuss testing at work and be regarded more as a trusted advisor. And it gives you a chance of listening to others speak and thus gives you access to learning from them.
What is strong style pairing? Are there circumstances under which strong style pairing is most suitable?
Are there circumstances under which it’s not suitable?
Strong-style pairing is an approach to pairing framed on the idea that we can keep the pair more engaged on the shared work by choosing how we split the work in the pair. In strong-style pairing, the idea of what to do starts with the person off keyboard as voicing out the idea. So if you have the idea, you say, take the keyboard. In traditional pairing it is the other way around, you pass the keyboard to the person with the idea.
For years I paired traditional style, and felt particularly disconnected with people I did not have a strong relationship with, or where our skills were either on different things (programming vs. testing) or we were on significantly different levels of skill. Strong style distributes the work and allows the person off keyboard to do more than review. And it solves the problem of how hard it is to talk while you write by not forcing you to carry both in the pair. Rules help with pairing with new people, and the same rules allow for growing from pair to an ensemble – more than two people sharing the task.
Also, a complete newbie to testing or programming would have hard time pairing any other way. Pairing is so important for new people, but to learn effective they need control over the pace, with their hands (and their working computer) on that control of keyboard. New people – well, established people too – don’t know how to ask for things they don’t know they are missing out on. Pairing reveals so much of that unknown unknown in tools, techniques, approaches and thinking.
Any style of pairing won’t be suitable if people are unwilling to pair. And when pairing, I have a personal preference towards strong-style pairing.
✍️ For more interviews, go here
📹 For my video interviews, go here
#Exploratory Testing #Interviews #Testing