Welcome to the season finale of the Quality Sense podcast! We started a few years ago, having conversations with different thought leaders and sharing their insights and experiences about software testing and delivering software products with quality, getting to know more and better the people that influence how we test today.

Today we are wrapping up the 4th season with an awesome guest… Maaret Pyhäjärvi. She has more than 25 years of experience in software testing and is constantly sharing her knowledge and helping others. She has experience organizing conferences around the world, meetups, and more. Maaret is currently working at Vaisala as a Principal Test Engineer.

In today’s episode, we talked about the challenges of organizing and attending conferences, and we dived into the topic of exploratory testing. How to define it, the challenges of building trust around exploratory testing, and more.

Get comfortable, grab a snack and enjoy!

Relevant Links:

Follow Maaret on LinkedIn
Follow Maaret on Twitter
Maaret’s Blog

Maaret’s Book Recommendations:

• The Complete Software Tester | Kristin Jackvony
• Testing Computer Software | Cem Kaner’s 
• Crucial Conversations | Joseph Grenny, Kerry Patterson

Listen Here

Episode Transcript

Federico:

Hello, Maaret. How are you doing today?

Maaret:

I’m good. Thanks, Fede.

Federico:

Welcome to the show. I’m really glad our friend Tristan connected us. And we have the opportunity to be talking and sharing time with you today.

Maaret:

Yeah.

Federico:

So I have to confess that I’ve watched many talks from you. I remember one in 2018, I think in Chicago. You gave a talk in Agile Testing Days. Is that correct?

Maaret:

Yes.

Federico:

Yeah. That was the first time I saw one of your talks. But also I watched many in different conferences because you are a very active speaker. But this is the first time we have the chance to speak. But I think there is a piece that I’m missing, which is how you ended up working in software testing. What brought you to this field? How you decided to work in software testing?

Maaret:

I didn’t decide.

Federico:

Uh-huh (affirmative).

Maaret:

I’m celebrating my silver jubilee, 25 years.

Federico:

Wow.

Maaret:

In testing this year.

Federico:

Correct. Yeah.

Maaret:

And 25 years ago, I had studied the Greek language. And I had started my studies in computer science in a university. And someone just put one on one together, and decided that, that’s going to be perfect profile for a tester. Can turn on a computer, apparently. And can read Greek alphabets. And I ended up testing the Greek Office back in those days. And starting from there, I just stayed here, and I grew wherever I could.

Federico:

Interesting. Interesting. I haven’t heard of even one person saying that they wanted to be a tester. In most of the cases, it’s by accident or by coincidence, I would say. And this is another example of that. Excellent. So the first topic I wanted to learn more about your perspective is related to organizing testing conference. Not only speaking at testing conference, but also organizing. What’s your experience organizing conferences?

Maaret:

I started organizing probably around 2000, just for kind of community things locally in Finland, doing meetups and wanting to kind of learn from other people around me. And organizing was just the perfect way of finding people that you want to hear tell you how to do that thing. So I would contact them and ask them to speak. And that was my way of learning. And I ran the local Finnish testing community for over 10 years here. Then, I decided that maybe Finland wasn’t the only place I wanted to learn in. And I started organizing an international conference. I worked together with a developer, Adi Bolboaca, from Romania. We kind of just got inspired over some open space where we met. And we talked about organizing this testing conference that wasn’t for testers, but it was about testing.

So for developers, product owners, testers, all of us getting together to talk about themes around testing. And that’s how European Testing Conference was born. So five years, I spent on running European Testing Conference, that was kind of an experiment. And I combined with European Testing Conference, I also combined a lot of themes around making sure that we have developers and testers both represented, but also having genders represented, having other aspects of diversity somehow represented. And I was trying to investigate if this whole pay to speak, basically the idea of paying your speakers rather than making them pay their own travel, so that they can speak on your stage, if that would somehow change the phase of the conference. So it was a whole experimentation platform for five years.

Federico:

Oh, wow. And now, there is a whole movement of people pushing to that idea of avoiding conferences that make you pay to speak, right?

Maaret:

Well, there’s at least a conversation ongoing.

Federico:

Yeah.

Maaret:

I’m not doing too well myself on avoiding those conferences. I just make it visible that I join conferences sometimes that are pay to speak. And I would really like to see that changed. But as an organizer of one of those conferences and having taken actually some of the risks and some of the losses related to those risks, I now believe that maybe the speakers don’t have the full picture of that in conference organizing, and while having to pay your own way to a conference, where someone else makes money out of that, it feels a little unfair. And it’s not maybe the best speakers for the audience that is paying. I believe that there is actually less money to be made out of conferences unless people are willing to pay significantly more than they nowadays are for getting their learning in conferences.

Federico:

Yeah, yeah. I understand what you mean. And also, it’s important what you mentioned, making that visible. Because in many cases, I consider some situations where I decided to pay to go to a conference and to speak, because it was convenient for me. But I made the decision, because I knew it was that way. So making that visible and having conversations about that, I think it’s better for everyone to know what we are supporting, or why, and how we are attending a conference. Yeah. Cool.

Maaret:

But also, it’s kind of like, not all of us have that choice.

Federico:

Yeah.

Maaret:

Coming from a low-income family, it’s not like I felt like I always had that choice unless someone paid or it was conveniently local so that I could just go without having to pay a relevant amount of money. It was not really an option. So I think we need to understand the social dynamics a little bit more around the choices that we’re making. Because otherwise, we end up just promoting basically the same people, usually the people already in a power position, and we lose some of the voices.

I did one talk at some point saying that anything that I say should be kind of, just don’t take it. Probably whatever advice I have, it won’t work for you, because I have acquired so much status over the years. The clout, the level of status that I have is quite high. So I can go and say to developers, I’m not writing a bug report, and that’s fine. But someone else doing that, they’re likely to be escorted out of the building.

Federico:

Yeah.

Maaret:

So just that realization is kind of important. We need to build that.

Federico:

Yeah. And also having the opportunity to co-organize with some friends in Uruguay, a conference. We have very different business model, I would say, to make it sustainable. I was talking with you before the interview about this, in our case, in Latin America. And probably it’s also related to the lower incomes that you refer to. In our case, we always offer the conference free for attendance, but we sustain the conference thanks to the sponsors, which is a different challenge. Right? It’s a different thing, but a different way to run a conference.

But yeah, the advantage, maybe in that case is that more people, especially what I can see in the conferences in Latin America is that, there are more junior people attending the conferences. Here in the States, in the conferences that I have attended, typically, you see people with more experience because they are already in the field, and they can earn enough in order to pay or maybe their companies pay for that, but it’s not the same in other places of the world. So we have to find what’s best for our communities, for the communities where we are running the conferences, right? So moving-

Maaret:

The big thing that I was trying to do over organizing conferences is this idea of finding speakers in a way that would be more inclusive. So first of all, I think it’s ridiculous as a conference organizer, looking at it nowadays, that we are selecting speakers usually based on their writing. Writing and speaking are completely different skills. And yet, we are selecting speakers based on what they wrote, kind of the marketing material they were able to produce, rather than the contents and the experiences that the person really has, and can bring to that stage, and is allowed to even share.

And the other part is, is that we tend to repeat the same things. Definitely, there’s many places where I can repeat the same message. And it’s a new audience, so it needs to be repeated. But also, there’s a lot of great content that never actually gets to be visible. Or we don’t get to distribute it in the same way, because we don’t help the newbie speakers enough. So that’s a dynamic that I really wanted to change as an organizer.

Federico:

You know, apart from the conference, what we found interesting, and I think you mentioned that you run a similar thing there in Finland, but having meetups as a safer space, fewer people, and maybe you can have more frequency, a meet-up every month, so you can bring more speakers, and you get to know them, and you give them the opportunity to rehearse their speaking skills, right? So in our case, it was a way to give the stage to new people, and then, invite them to participate of the annual conference, because we already knew how they perform, speaking in front of a smaller group, and how they spoke, and yeah. Is there anything you see missing in testing conferences today?

Maaret:

I think we are still speaking too much from the tester’s perspective and not enough from the testing perspective. So in this world right now, I feel like product owners are the new test managers. And we don’t see product owners in testing conferences. Developers do a lot more testing than they used to, and they are a very, very small minority in any conferences with testing topics. It’s a growing minority, but it’s still a minority. So I feel like maybe the missing part is somehow the intersection of how widely testing actually impacts organizations and how different people look at it from, well, whatever positions they hold.

Federico:

I’ve heard many times things like, “Testing is not sexy enough to bring those other roles interested in the topic.” So do you have any strategy to make the topic or the conference more appealing to developers, product owners, or someone else?

Maaret:

So I don’t know if it is that it’s not interesting enough or lucrative enough. Maybe it’s more about what kind of things around testing we talk on, on there. So practical cases, how we do things, examples, especially from real companies doing testing are generally a lot more interesting than somebody telling that they read a book, and now they think that testing is somehow connected to whatever they read last. Well, we have many different brands or different types of talks that we usually stage in conferences. And making choices on those probably would help us bring a more equal crowd. But then again, I also like the fact that we’ve always had these safe corners for testers, where we can go, and say that we are sometimes having trouble being so alone and being so different, and it’s so refreshing to be able to be with people who know what that feels like, when you have to always kind of hold back on the joy that you get on the bug that you found, because the other ones, actually, they don’t get the same joy out of that bug. The bug is more of a nuisance. So you’re always filtering, your every day is filtering. And it’s just going on a community that allows you to show your true emotions, in a way. You also need that. So maybe it’s more of, we need these bridging places, but we also need those corners where it’s okay for us to be kind of amongst same kind of thinkers. So in that bubble, which gives us the energy of, again, trying to constructively take things further.

Federico:

Yeah. Maybe attending different type of conferences with different goals in mind. One, is to feel safer and to share these emotions and these experiences more from what we do every day, and in other conferences, maybe it’s learning and empathizing with other roles. Okay, this is how a developer presents their learnings. Or this is what they are worried about. I don’t know. But at the end of the day, we can get a lot of benefits also as a tester to attending different types of conferences as well, right?

Maaret:

Yeah, definitely. I haven’t been only to testing conferences. And I don’t talk about testing only in testing conferences. So I’ve at least already had the chance of going around. But I’d say that for a typical professional, it’s not like you get to go to multiple conferences a year. If you get to go to one every five years, that’s already quite good, actually. Not everyone gets to go continuously. Well, free conferences, online things, on your own time, definitely. Or even at the company hours, if it’s sometimes a couple of hours here and there, and it’s a well built story, and not an expensive one. Definitely, get to go. But it’s not like we get to choose tens of conferences so that we get all the different dimensions. So whenever we go to one, that’s actually where we’re looking for those bridges. And the conferences are the places where we build those human-to-human relationships usually, especially between speakers. Some of the developer speakers that I work with… Well, organized conferences even with, I’ve met them in other conferences. And those bridges, the organizers need to be intentional about those.

Federico:

Interesting. Very interesting. Another topic I wanted to cover with you, it’s one of the things that I know in those almost 25 years you have been researching a lot and sharing a lot, which is exploratory testing. And maybe to start helping the audience to level up and having the same idea. How do you define exploratory testing or how you explain it?

Maaret:

I’ve been really looking for the right way of explaining it, because it’s not an easy thing to do. Definitely, the core of it is learning. So whatever you are doing right now, and you’re learning from it, it has an impact on whatever you’re doing next. And other than that, what you’re focusing on is results. So what I, nowadays, try to explain it as is that, there’s this kind of results gap. Thinking in perspective of an organization, there’s a certain level of results we want from our testing activities, be them testing before production or testing while in production. We want to have certain level of information, knowledge, actionable information about quality and whatever is going on in the organization. Then, there’s the gap. There’s a gap between what we’d like to have or what we would need to have and what we actually have. And that gap is completely invisible. Sometimes it’s very small. And exploratory testing is just kind of going that extra mile. Especially, Agile makes these promises of other mechanisms than exploratory testing, where we are really carefully in small-scale designing continuously in a particular way. And that gap would be smaller. But there still is that gap of uncertainty. And exploratory testing is trying to get to that gap. In some organizations, it’s a really big gap, and others, it’s a very small gap. But it almost always exists, I will say.

Federico:

In many cases, when we were working for a customer, mainly when it’s a new company, and they don’t know us yet as well, and maybe we are building the trust, right? In many cases, when we explain that our preferred approach for this particular case is having an exploratory testing approach, they will miss the control, the coverage, or how you know you tested enough, right? Is that something that you also faced when you are mainly in that stage where you are building the trust?

Maaret:

Yeah, I do face that a lot, to some extent. Well, the older or more senior I get in this industry, the less I have to struggle with that. Just saying trust me, nowadays, works. But I’ve had to deal with that a lot of times over the 25 years. I remember this one particular organization where there was a project manager who just didn’t feel like testing was work that anyone would do voluntarily. So if I said, I’m going to do exploratory testing, it must mean that I’m having coffee, because no one would test if they are in their right mind, that was the mindset. And what I did for about a week is, is that I wrote really detailed notes and visualized, kind of like organized and visualized my notes in particular kind of exploratory typical structures that we create. And I created so much material that it would’ve taken him more than a week to read it. The results of my week of work, there was a high-level picture, but also the details of everything that I thought while I was testing. Well, that particular project manager never asked me again for doing any other style of testing. So sometimes by means of experimentation, showing kind of like on a short-term contract. Can I show you how I would do this? And making it really visual and just creating some kind of an outline for that coverage as well. You can measure against requirements. You can measure against code. Especially if you write automation on a unit level, you can run it against code coverage as well. You have those mechanisms of making it visible what you’re doing, and creating that trust by visibilities, kind of the way to go.

Federico:

Creating the trust by visibility. I really like it. Another thing that typically is, I would say, a blocker or something that people repeat a lot of times related to exploratory testing is that we need an expert to do it. For a junior tester, it’s much better to follow the scripted approach, because we are telling you what to do, and you just get the script, and go through all the steps, and report their results. What do you think about it?

Maaret:

I had a 15-year-old in one of my jobs. And I was trying to get them to do exploratory testing, and then, their dad, who was a developer in the same company, interjected and required scripted approach. It didn’t last very long before I corrected them again. But we got this, like a moment of the two things side by side, kind of like during short timeframe in a very early career stage. And their results might make an appearance of progress and the scripted approach. But their results were not worth much in that style. Whereas, in exploratory style where we would regularly get around the whiteboard and make sure that he had learned about the application and had a better sense of what is meaningful out of those results, he grew a lot faster that way. So I personally think that no matter how many years you have, you’re better off learning than trying to just follow somebody else’s instructions.

Federico:

It is more like a waterfall-ish approach to testing. It’s like there is someone designing the test cases than someone running. And the learning, maybe it’s at the end. And in the exploratory is a shorter iteration for that learning to happen. Something like this.

Maaret:

It might be that. And it’s also kind of like the idea that even if it’s you, yourself that earlier wrote those scripts, if you repeat the same scripts, it’s like you’re walking on that minefield on somebody else’s footsteps, and since somebody was planting new mines somewhere, your previous footsteps might be a good place to look at. But you might actually want to just intentionally take steps just a little bit sideways, and with the same amount of time invested, do something more than you could do if you just follow the same footsteps. So in order to try to save time, we sometimes take a lot of the value out of the activity, and it’s always a balance on how much we document what’s helpful in remembering. But usually, leaving it to a level where people have agency, they have to decide themselves on what they’re learning and what they do with the information they’re acquiring. It creates better results.

Federico:

Amazing. Perfect. So, the other question I have for you related to exploratory testing and an article I really liked that I referenced recently in one of my talks, it was more related to the automation approach related to the famous or infamous testing pyramid. And you were mentioning something like, or this is at least what I understood, that instead of considering the exploratory testing as a cloud on the top of the pyramid, we could take an approach, an exploratory testing mindset in each of the layers we could apply that approach or that mindset, even when we are designing or running unit tests or API tests. So I would really like if you can expand on that idea a little bit.

Maaret:

Yeah. It’s definitely been one of my pet peeves, this whole idea of the cloud on top. And I’ve been trying to get certain people to stop drawing it as a cloud on top, because it’s like a cloud hovering over every single layer. And sometimes it’s kind of like overlaying more than half of it, depending on how much of a learning mindset your team otherwise has. So the more strictly you follow somebody else’s plan, the more you are relying on the exploratory testing, bringing that learning mindset into it, and some agile teams are really good at the learning mindset already, even in like a traditional TDD, which is a little bit different thing. 

So I’ve been doing on conference stages, I’ve been doing presentations on doing this on API level, doing this on unit testing level. And one of the most recent exercises that I’ve been building in the last couple of weeks is one where we use GitHub co-pilot as the programmer in a pair, well, actually a trio because that’s the third person in this, this pair or group ensemble, and he writes all the code and we are supposed to do all of the testing and then doing exploratory testing to figure out if whatever the co-pilot created for us was worthwhile. And if there is something that is actually missing in order for us to build the right solution with our copilot, this is AI that writes you code, or it looks like a search engine that searches bits and pieces of code somewhere, but still kind of figuring out whether that works and whether it’s the right solution for your problem, whatever the code is that you end up with. It’s a bigger part of the future than what we maybe have thought about.

Federico:

I’m really curious about how would you explain the coverage that you are getting by doing that exploration with that experimentation. How big is the gap of information that you have, as you were explaining before, right? Because as we are talking about machine learning and algorithm writing code automatically, so the possibilities are endless, right?

Maaret:

Yeah. But also we are writing kind of small pieces at a time, usually. It’s a very specific algorithm that we are generating for a particular purpose or a very specific program that we are creating for a particular purpose. Then the question is about, do we really understand the problem? The problem that I’ve been now playing with is Roman numerals. And it’s interesting. I had this one guy from Spain that I was pairing with, and he was like, “Oh, I am a total domain expert on this one. They teach us Roman numerals in school.” And, and he was impressive. Given a number, he could just turn that into Roman numerals without a reference. Seriously could, and I could not. And like, “Wow, that’s awesome.” But then we discovered that there’s numbers that are above certain limit and that you can actually also handle that the school system never taught, but there’s information online.

There’s fractions that can be handled, which again, the school system never taught him. So he was a domain expert in a certain way. Also, we discovered there’s five different ways of generating Roman numerals, five different rule sets, so to speak, in Excel as a reference. We went through this kind of five layers of Oracles from works as implemented to works as we thought it should. And actually, we went and did some research to also kind of like having reference implementations, to having also error cases handled. We went through all of this in an hour and it’s kind of an interesting thing because what I’ve learned over the years from research basically is that in hindsight if we look at production bugs, the bugs that escaped to production if we look at them and we create a fix, and then we think of how we could test them, over 90% of them could be reproduced by a unit test.

So I think that’s one part of the gap that we are trying to actually get to on the unit level so that we could get to that 90% level rather than having to find it all on the higher layers. So getting to that small scale and doing careful work on that smaller scale and leaving behind some kind of artifacts that help us also maintain that level when we are making quick changes. I think that’s a big thing that we need to learn to do better in the future, but it’s never just unit testing because not all bugs can be found with unit-level approaches. So we also need the other layers.

Federico:

Yeah, absolutely. Now I’m thinking about the problem because you say it’s important to find the problem and to understand what you are trying to improve. Were you trying to improve the specific unit to generate the Roman numbers? Because that was generated by an autonomous assistant, right? That probably is being used by so many developers at the same time. How can we contribute to that? If you find a bug in that particular case, you can solve it in your generated code. How can you get that learning back to the source So other developers using the same assistant can also improve it? because I’m thinking about a very bad future where we are using an assistant that is introducing bugs everywhere and nobody’s giving feedback to that algorithm, right?

Maaret:

Yeah. And it is really then, well, multiplying the bugs. And again, Roman numerals is an easy play example in the sense that there’s definitely a lot of openly available solutions. So I could just Google for some of those solutions and test them as well, but they very often actually come without tests. So they are not delivered with tests necessarily, or some of them are delivered with TDD style tests that might still not do a very good job on even covering the scenarios that we might want to cover on the unit level.

Federico:

Yeah, it’s the same case than copying and pasting buggy code from some repository in the internet, right? And maybe adding more effort to the unit level, as you were mentioning, can help us as an industry to do better in the future. Right?

Maaret:

Yeah. It probably would.

Federico:

Cool. I have a very generic question to try to wrap up this part of the interview, which is from your experience, what’s the most effective ingredient for a successful testing strategy?

Maaret:

I’ve been trying to figure out for years what the strategy really is, and I’m not sure if I understand that in practical terms, at least. Like in a way I think of strategy as kind of the ideas that drive our test designs. So whether it’s the ideas that drive our automation on how we would do automation, or how we do all kinds of testing, kind of all exploratory testing, that also includes automation for me. For me, the way that I’ve learned to do a strategy is kind of look at the risks of the product, and think in terms of those risks, and how I would test to find them. But I see a lot of strategies that people write that are more about process descriptions or working agreements, which I don’t think are necessarily strategic thinking as such. And my rule of thumb over the years has been that if the same strategy works on two different products, it’s probably not specific enough, because there’s a reason why two products are separate. And it’s usually not just that we want to build it twice in the same organization. So we probably want to figure out somehow what’s the core of that product and how the risks for that specific product kind of show up in the way we would test.

Federico:

So probably one of the things that we have to realize is what’s the specific things that apply to this context, to this project, that are different from the previous project that I was working on.

Maaret:

So I’m not even sure if it is about the context like we’ve been talking about context-driven testing for years now. And we kind of have this idea that there’s somehow contexts are different, but actually what we’re saying is people are different. And some people today with their today’s capabilities are able to do certain things and they are not able to do other things. So is it then strategy that we say that “Okay, we’ll accept that the 15-year-old doesn’t yet know how to program.” Is that a strategic thing, or is it just more like just facing whatever are the facts of today? And the strategic thinking is more on kind of like we are growing our competencies towards something else in the future.

So I find that thinking in terms of strategy, hasn’t really helped me. Thinking in terms of short-term, long term has helped me. Thinking in terms of growing individuals and benefiting on group level, the skills of today in a group, that has helped me, and appreciation of the good things we are capable of doing today, even though they are not perfect, that has helped me a lot.

So a lot of times I go to an organization and I’m like, “Oh my God, this is so bad. This is so awful.” And then I need to ground myself in saying that actually, they’ve been able to make releases on some kind of a fairly regular cadence, maybe with more pain that I would like to be enduring myself, maybe not in ways that I think this group is already capable of, but looking at what they’re doing, they are as a matter of fact, not capable of doing those before someone injects those ideas in. So kind of moving teams rather than thinking in terms of a strategy that we are right now applying, creating work in contracts, just replacing that word in its entirety, if possible, is what I would advise people to consider, because we’ve made it almost like a template that we’re trying to apply on everything, and then we layer the contexts, making it fuzzy enough, not to be practical anymore. So if I create a strategy, it’s about kind of what’s the product, what are the risks of the product, and how would I test, what are the specific testing activities that I need to have in order to address those risks that I identified. And I usually do that in an exploratory style, which means I don’t do it before I test it. It’s an outcome of the testing I did. It might be a midway outcome, but it is not starting the testing. It is a continuous description that is finalized when I’m done with testing, rather than the other way around.

Federico:

And as I understand, from what you just said, understanding those things can help you understand the needs, the skills that you need in your team, and accommodating or preparing or helping the people to get those skills if they don’t have them. That’s one of the key things for success, right?

Maaret:

Yeah. And we are always balancing our efforts today between being individual contributors who are productive, and then being people who are making others better by being generative, kind of like generating better individual contributions, and we are balancing the short-term benefits today and the long-term benefits in a year or two. So we’re always balancing. I see in front of my eyes four different areas and I’m always trying to do all four of them. Maybe that’s how I think of strategy nowadays, that I want to make sure that we are ready for the future, but I also want to very much live in today, both on an individual and on a team level.

Federico:

So with those quadrants, you can plan different activities and different things in order to move your team forward. Right?

Maaret:

Yes. And again, I also can make sure that it’s not just kind of like one quadrant isn’t one person’s job, but everyone gets to be a little bit in all of the quadrants. Cause that’s how we grow. When we learn to actually cover all four quadrants on an individual level, that’s probably going to help us grow as professionals.

Federico:

I really like how you connect quality strategy and everything, also, paying attention to how your team and the individuals in that team are also growing. This is an amazing way of considering all the corners of our job and our responsibilities. Thank you for that. But I have one final question for you. If you have to recommend a book, it could be about software testing or any other topic you like, which one would that be?

Maaret:

This is a really difficult question in the sense that there’s kind of a couple of categories of books that I would generally go and recommend. The new book from Kristin Jackvony on “The Complete Software Tester”. I would definitely recommend that as a good overview on what’s going on in testing, but it doesn’t really help me at this point. Whereas if I would read a book, well, when I do read a book, I’m still going back to Cem Kaner’s “Testing Computer Software“, even though it’s older, it really well kind of describes the difference in the mindset on the product companies and the exploratory testing style and still drill us in quite deep. Even if some of the bugs that are maybe presented are a little bit old-fashioned there nowadays. And if I’m looking more on the kind of human side, then “Crucial Conversations” is an absolute read for any professional. So learning to tell people what you think, what you want, what you need and help them go forward when it matters and knowing when it matters. Like that should be the number one book for any tester.

Federico:

Interesting, interesting, I’m making notes. And I will share also the links to the books in the episode notes. But I thank you so much for your time and all your knowledge and everything you share. I really appreciate your experience and having the opportunity to talk with you. Is there anything else you would like to invite our audience to do or reach out or anything?

Maaret:

I’m always on Twitter. So that’s where all of the stuff that I generally share is available. So please follow me on Twitter. @maaretp, M-A-A-R-E-T-P is my handle. And I’m always happy to talk about testing. So that’s the invite.

Federico:

Amazing. Thank you again so much and have a great rest of the day.

Maaret:

Thank you.

Federico:

Bye.