Interview: 7 things every novice should know about test automation

Meeri (00:00:05):

A lot of times there would be entire meetings where I understood nothing. There would be a slideshow someone would be presenting, they would be having whole conversations, and I would have absolutely nothing to contribute because I just didn't understand anything. Nothing was in context. Nothing seemed to make sense. And then sometimes I would be asked for an opinion, and I would have to be like, "Um, I don't... Yes?"

Lauri (00:00:34):

Hello, and welcome to The DevOps Sauna. We have all started our career from somewhere. Some people may have known exactly what they were up to from the get-go. But most of us, we're walking the path zigzagging through different roles and responsibilities. When someone is in the early stages of their career, it can be helpful to improve their skills in metacognition and reflection.

Lauri (00:00:57):

Meeri Varis recently had her first summer job in a systems testing team, and we asked her to share what she thinks are the most important matters for every novice going into test automation and quality assurance. Meeri is joined by Saara Laakko, a DevOps consultant from Eficode. Let's give the mic to Meeri and Saara.

Lauri (00:01:12):

Thank you for taking the time, Meeri and Saara. How are you today?

Meeri (00:01:12):

I'm doing good. Just working on school as usual. Having too many courses as usual. Trying to learn statistics, which is proving to be more difficult than I would like it to be.

Lauri (00:01:41):

Thing to remember about statistics is all models are wrong, but some models are useful.

Meeri (00:01:45):

Yeah. Yeah. It's like that Finnish saying where, it's probably a saying in other languages too, where it's like, there are lies and there are major lies, and then there are statistics.

Saara (00:01:53):

Yeah. Statistics were the worst for me.

Meeri (00:02:00):

Yeah. I don't... It's difficult. It's very difficult.

Lauri (00:02:04):

How are you, Saara, today?

Saara (00:02:06):

I'm good. Just working with customer and hustling. I don't know. I'm just good. Just having a little bit of back problems, but it's okay.

Lauri (00:02:18):

Ooh.

Saara (00:02:19):

Yeah.

Lauri (00:02:20):

Today we are talking under the title Seven Things Every Novice in Test Automation Should Learn. And really, before we go to this conversation, I have to ask both of you to set this straight for me because I come across it from time to time, and it's a terminology issue. We say test automation, but then I also hear something called continuous quality assurance. And so what's your take on this? Let's get the term straight, what it is.

Meeri (00:02:51):

With my three months of experience, I always kind of... Test automation in my opinion, tends to be used in situations where we're specifically talking about the automation that we have, kind of, at least the way I interpreted it would be. Now we're talking about code, and then there's a whole bunch of other terms that can be interchangeable like that and they all have their nuances. But then I would usually just assume that we're talking about this in a bigger scale, usually to have to do with customer requirements or something like that, where it's higher up in the business... company level.

Saara (00:03:43):

Yeah. That's a good point. I would say that test automation is a part of quality assurance. It may be the whole part, but usually it's a smaller part and quality assurance takes it a little bit further and takes account of everything else, quality advice... Well, as you said, to requirements, everything and test automation just uses those and it's a whole package.

Lauri (00:04:19):

There's also the unpronounced assumption that when we say test automation, that there would also be a test which is not automated, which I'm pretty sure that we get into as we go along the way. How we have structured this talk is, as it happened, when Meeri told that she got a role as a summer worker around test automation. And I asked her to think about... be reflective of what's going on and what should every novice know, now that truly she had a chance to come in as a novice for test automation. And she went and did what I asked, and thank you, Meeri, for that.

Lauri (00:05:04):

And we have seven, let's say, statements that she observed as part of her work. And we are today going them through first giving floor to Meeri to make the case for the statement. And then Saara with more experience under your belt on test automation, continuous quality assurance and all other those buzzwords. Then we get to hear a reflection, and then we'll take it from there. So shall we get to it then?

Saara (00:05:30):

Sure.

Meeri (00:05:31):

Sure.

Lauri (00:05:32):

Number one being, "Don't underestimate your skills but make sure you really understand."

Meeri (00:05:39):

Well, this is a big concept, I feel like. And especially coming from the school world where we're basically graded and we're always judged upon what specifically are the things we know like the amount of knowledge we have and the quantifiable understanding that we have. It's really easy to overlook all of those type of soft skills that you might have.

Meeri (00:06:13):

And then also it's really easy to learn to question that kind of intuitive way of thinking where if I don't really have specific arguments for something, then I'll be very hesitant to even bring forth what I think because the way that we're taught in school is just anything you say you should be able to prove or give arguments or give support.

Meeri (00:06:44):

And I really found that in a lot of situations at work, and especially in team conversations or those type of situations where it's a lot about interaction and exchanging knowledge, there are a lot of situations where I would be hesitant to say something. I would have a thought in my mind and then I'd be like, "Well, I don't know enough about this," or, "Well, I don't have specifics for this," or, "Well, I don't have any support for this." And then I wouldn't say it and then someone else would say it and might even say it even more vaguely than I was planning to.

Meeri (00:07:25):

And so that's what I learned is just to kind of linger in your mediocrity in a way. It's fine to not be the expert. It's oftentimes needed that the not-expert says something on the matter, and then oftentimes it can be a really valuable point of view from that non-expert.

Meeri (00:07:54):

But then the flip side of that is to not get cocky. It's easy to then go, well, for some people it's easier than for others, but then there's the danger of going all the way to the other end and being like, "Well, I'm always important in all the conversations." Which is also not always true.

Meeri (00:08:20):

And so, it was something that I needed to learn was to be more confident in assuming that I do have the knowledge that I would need for this conversation or for this situation or that I would have an important point of view. Then one always has to keep in the back of their mind that, in reality, there are a lot of things that we don't know, and then should always be able to take that feedback of, "Well, you might be wrong," or then just be wary of not getting too noisy in situations where you don't actually understand.

Saara (00:09:13):

Yeah. Super good points. I wanted to touch upon that, but make sure you really understand in this test automation point of view a little bit because, at least, I have noticed that really often you might need to justify your work because test automation might cost a lot, at least in the beginning, and if it's done, probably... So I would say that's the one aspect I would keep in mind going as a novice in test automation. Because while software testing, in general, might be a little hard and you need to communicate all the time.

Saara (00:10:06):

And the points you made were excellent just to show that it is what it is and you need to be vocal, you need to ask questions, and you need to just develop yourself further and further, and just, I don't know, sometimes maybe make a fool out of yourself. My coworker just said that your best quality is that you are never quiet. And I was like, "That doesn't sound good." But I learned to do that. I was not like that at all, at the beginning. I was so shy. I didn't ever say anything and never asked any questions because I thought that everybody would think that I'm stupid or something like that, but it's not like that. You're learning. And you're always learning, even as a specialist. But yeah, super good points.

Meeri (00:11:06):

Yeah. About justifying your work? I kind of feel like coming as a complete novice to specifically test automation and to specifically go to build automation and make code for the automation code base. Some of my work should be self-justifying. A lot of my work would just be very basic stuff. And a lot of my justifications would be, "Well, we don't have it yet." It's like, "Why are you testing this button? We have nothing. It doesn't exist yet." "I'm making it." And so I haven't really run into that situation yet because I was doing a lot of stuff that was very basic and very obvious as to why I was doing it. But yeah, I do relate to that.

Lauri (00:11:59):

You made a point earlier saying that at school you were taught to prove your arguments or basically argue your statements, is maybe a better way of saying it. Maybe that is because at school there's an underlying assumption that it is possible to find an objective truth. Whereas when you think about any business setting, it's probably not even that clear that you want to find the objective truth.

Lauri (00:12:28):

I think Albert Einstein was saying it in the way that of all the possible theories that are out there or the models that are out there at any given time, one of them proved to be far more superior than the others. Robert Pirsig in his book Zen and the Art of Motorcycle Maintenance, he put it nicely that some people take offence for the fact that truth is time-bound.

Lauri (00:12:52):

And I think it is helpful irrespective of whether it is test automation or anything else to think that we are not on the quest for finding the truth, especially dogmas that are true irrespective of time, but we are trying to find the best plausible, implementable alternative of all the alternatives that does the job at this moment. And somebody can know it better and it's okay. But then after all of this going back and forth, we can accept that, "Okay. It's not important to find a truth. Let's just pick one and go with it. And if we prove ourselves wrong, then we'll do something else."

Saara (00:13:35):

My professor once said to me that perfect is the enemy of good because I couldn't let my thesis go. I couldn't let it go, and he was like, "It's okay. It's good. It's already good. So just... you need to learn this." And that's what I've been doing now after my graduation, in work.

Lauri (00:14:00):

Yeah. Done is better than perfect is another way of saying the same thing.

Saara (00:14:06):

Yeah. True.

Lauri (00:14:06):

Yeah. Shall we move to number two? I think we have already been talking about it a little bit, "The people are your only good resource."

Meeri (00:14:15):

Yeah. This comes from a lot of experience of a lot of desperate googling and finding nothing but confusion. I think the problem specifically for a beginner, a novice, is there's so much information on everything, it's just always available, always there. You can find really the answer to any question, always. The problem is there is so much of it, with very little experience in the actual matter, it's really difficult to filter it.

Meeri (00:14:53):

So it's very easy to just kind of get down this rabbit hole of clicking links and finding answers that you vaguely understand or not really understand at all. And then finding kind of a familiar term and then clicking that and then getting just very tangled and confused. And oftentimes I would be tangled and confused and then ask a colleague or a senior member of the team and they would read the same exact article and then give me a straightforward response based on that, just like that. Because experience, I think, gives so much insight and so much perspective into filtering all the possible answers that one might have for that question.

Meeri (00:15:47):

And then finding out what, which of those answers is the one that we actually want to use here. That's what I mean, is there are other resources. Yes, of course. And all of the knowledge that the people around me would have, I could probably find somewhere else. It's just, it takes so much time and so much effort to be able to understand and arrange all of that information.

Meeri (00:16:14):

And then, I like to think that as a junior member of team, it is a part of my job to be asking for help and to be learning. My role in the team is to be the one that is learning the things. And so it's easy to see it kind of as a shortcoming to be always asking questions, but then I would just be like, "It's my job to not know things and to ask for them."

Saara (00:16:46):

Yeah. Yeah, for sure. It is your job to ask questions. And it's beneficial to the senior members also in the team, to be asked those questions because sometimes there are questions that they don't even think about and they need to think about that. And I totally agree that people are a really good resource. I always encourage to reach out to someone in your team or in the company or whatever, your schoolmates might know a lot.

Saara (00:17:26):

And it's always a good thing to listen to people. I do also find pages like Stack Overflow, Guru99, and TestingXperts, those are just a couple of examples of really good, good pages to find information about test automation. Stack Overflow, maybe more with the coding stuff really. And well, I think every coder knows Stack Overflow for something.

Saara (00:18:00):

And also I have experienced that there are these communities, in a way, like in CI tools or Robot Framework has its own community that you can join in Slack or somewhere and ask questions. And there are these experts that are really doing the tools to do test automation. And that's a super great way to learn and ask new things.

Saara (00:18:36):

One point that I had also was that, this little bit mix-ups with the first point that we made in the beginning, because I would say that you could learn these things and find those articles yourself, and then just bring them up and be like, "Would this be good? Is it good idea?" And just be vocal about that too. Because if you're not sure, you can just ask and then you show you have really done your research and really tried to come up with an answer. I think that's a good way also, in the beginning.

Meeri (00:19:17):

Yeah. Yeah. I think that's something that I might have done a couple of times where I had an idea of what I might be wanting to do, but that would be kind of later in the summer where I had a little bit more experience with what might be useful, where I could judge for myself what might be applicable. The problem was for me, at least in the beginning, was a lot of the articles and a lot of the resources go really deep and really specific and then use a lot of that kind of, not necessarily maybe jargon, but very field-specific language that I wouldn't know at all. And so then it would just be a lot of work to try to even understand the language.

Saara (00:20:07):

Yeah. As Lauri said, "In the beginning, there's a lot of terms that we're using."

Meeri (00:20:16):

Yeah.

Saara (00:20:17):

It's just our way to sound super fancy.

Meeri (00:20:19):

Yeah. The biggest skill I think I learned during the summer was to group the things that I need to know and the things that I don't need to know. I would learn, "Okay, this is for me. This, I know. This, I need to listen to." And then, "Okay. I don't need to know about this. This is for someone else. I can just do something else now." Or, "Well, that's a term I've never seen, but well, probably won't see it again, so."

Saara (00:20:51):

Yeah, that's a good way.

Lauri (00:20:55):

Did you, Meeri, come across job titles, also people with a role that helped you in your test automation effort in a way wouldn't have expected?

Meeri (00:21:09):

I think I had a pretty decent grasp of what the people I would be interacting with might be. There weren't a lot of job titles that I would be like, "Oh, this one's helping me." But there were a lot of job titles that I'd never heard before. Things that I didn't know were jobs. And so in a way, yes. Then once I learned what those jobs were, I could see how they would be helping me or working with me.

Meeri (00:21:44):

But yeah, the most memorable was a product owner. I had absolutely no idea what it meant. The product owner of the team was just presented to me as, "This is the product owner." And I was like, "What? Owns the product? Owns it? How? Isn't it the company's product?" And so yeah, there were other things like that, where I just went, "Oh, didn't know that was a job." So in a way, yes.

Lauri (00:22:23):

Yeah, very, very early, not even in my career, but some of the jobs I did when I was very young. I was working in a hardware assembly in one of the Nokia subcontractors. And basically, I had a desk where I was sitting down and I had some screws and some of the PCP boards and connectors and I had a screwdriver. And there was a jig where I had to put the lower part and then I had to put the upper part in and then screw it in and then take the ready assembly out and put the next in. And it was basically a physical repetitive job associated with things like base stations in mobile networks.

Lauri (00:23:07):

And I was doing the job. And then somebody who was basically running that factory came to me and observed what I was doing. And then he looked at the lots that I had finished. And he said, "That item and that item and that item are not assembled properly. You have to dismantle them and reassemble them. And this is what is wrong with it." And maybe I had a bit of a cockiness that you referred earlier, so I asked him like, "What do you know of this job? You are a production plant manager." And he said, "I designed the jig." So you never know who happens to know about the area that you're working on. Which nicely leads us to the third topic. You, Meeri, labeled it as, "Observations are key."

Meeri (00:23:58):

Yeah. This was kind of a personal journey about communication for me. And this directly comes from a conversation I had with, not directly a supervisor of mine, but a senior member of the team, where this is what they refer to as cotton candy around a lot of the language of a lot of the juniors in a lot of situations when I would be asking for help or talking about something. I think, partly for me to be able to form the actual question that I was asking and kind of arrange my thoughts for myself, I would be introducing a lot of these like, "Why am I doing it? And what am I trying to do? And what do I think is wrong with it?" and would kind of not enough be describing what is actually happening.

Meeri (00:25:03):

What would be really useful for the people around me would be me going, "I want this to do that, it's doing this instead." And that's kind of, I think, the bigger picture of that is to try to learn, to think about, or talk in terms of actual observations, actual things that I see, the things that are concrete, that I can actually show them, that I can present. I don't need to know what's happening or why it's happening, I just need to show them what I see.

Saara (00:25:44):

Hmm. Yeah. I have seen this many times, especially in manual testing. I have done that quite a bit in my earlier career. And in that way, it's super easy always, usually, to show. Because as a tester your job is kind of tricky because you need to tell others that they have made a mistake and you go to the developer and you say that, "There is a mistake now, you have made it." And then you need to show it, possibly many times, usually many times because they do not believe you. But yeah, that's totally what... I agree with the real facts, you have a background for your arguments.

Meeri (00:26:40):

Yeah. And what I found with, especially oftentimes when I would find a problem or find out what I thought would be not necessarily a bug, but a problem. I was testing a lot of these type of user interfaces or I was doing a lot of app testing. And so I would find a problem. And then I would go to the developer and be like, "This is a problem." And then they would just respond to it, "No, it's not. That's how it's supposed to work." And then I would go, "Yes, I know it's supposed to work like that, which is a problem because..." And then I would just have to go, "If I do this, then this happens. And then if I do that, then this happens. And then if I do that, this happens. But then if I do that, then it doesn't happen."

Meeri (00:27:30):

And so that was really a very useful skill to be able to just show, "This is why it's a problem." And then concretely share my screen and show them what it's doing and why it's a problem. Well, it's way more difficult to argue something with, "Well, it's just inconvenient and it makes it slower and it's annoying," than to just show them what's happening. And yeah, I ended up doing some back and forth sometimes with, "It's supposed to do that." And then me going, "It doesn't make any sense that it does that." Of course, in a friendly way but that was the concept of, "This isn't useful for the user."

Saara (00:28:21):

Yeah. It's totally like that because sometimes developers might be so into what they're doing and so into the details that they don't even see the full picture. And then when a new person that's especially good with coming as a new... and don't have any experience in testing or test automation, it's really a great thing that you can just look at it in objective way, not in like, "This is my baby now and I need to take care of it, even though it's not a good baby, but it's my baby still. But I don't want to do anything about it." So they don't want to sometimes maybe take the step back or they just can't, it's just super hard.

Meeri (00:29:16):

Yeah.

Lauri (00:29:17):

Sometimes it may be that you are scratching the surface of something that really hasn't been thought through, it just has organically become to be what it is. And then you said earlier that your role is to ask questions. It could be that collectively people have just concluded it to work this way. And then when you get a third opinion who starts to question the foundations, it could turn out, they aren't. And then you have to go to the roots and then you sort of reconstruct the reason why it behaves that way. And then if that set of arguments doesn't hold, then you know there's a problem. So you are sort of stimulating other people to think it through one more time if it happened that they didn't do it in the first place.

Meeri (00:30:09):

Yeah. There was something I remember, I don't remember specifically what it was, something that I found that I thought was a problem. Where I made a Jira ticket, and then it would get solved and then I would test it and then it still didn't work like I wanted it to. And then I would just open the ticket again and then they would close it again. And I would open it again and then they would close it again. And at some point I went to actually talk to the developer and like, "What's the case with this? This doesn't make any sense? Why are we having this kind of interaction?" And then the situation resolved itself once we had the conversation. But it was kind of a funny situation that came into my mind.

Saara (00:30:51):

But it was right for you to go and talk to the developer because that situation would've never been resolved otherwise. I think sometimes it might be just that they do know that there's a bug problem, they do know that there's a bug that's now a feature, and then they just ignore it. So that's why it might be even painful to recognize some of the things.

Meeri (00:31:18):

I think it was exactly that type of situation where I was like, "This is a bug." And then they were like, "Yes. It'll get fixed later or it won't be a problem once we have fixed this other one," or something like that. And so it was kind of a misunderstanding, but it was also funny in terms of ineffective communication.

Saara (00:31:36):

Yeah.

Lauri (00:31:38):

All communication fails except by accident.

Saara (00:31:43):

Yep.

Lauri (00:31:45):

Most of you may agree that maintaining adequate test coverage is important, but for some reason it is easily forgotten or just blatantly ignored. Krristiina Lindholm has written about whether you manage your software or does it manage you. Her topic connects to test automation, technical debt, and application management, in general. You can find the link to the blog post in the show notes. Now let's get back to our show.

Lauri (00:32:12):

Moving to the fourth one communication having to do with language. Number four, what you listed down, Meeri, was, "Don't spend all your time trying to learn their language."

Meeri (00:32:24):

Yeah. A lot of times there would be entire meetings where I understood nothing. There would be a slideshow. Someone would be presenting, they would be having whole conversations. And I would have absolutely nothing to contribute because I just didn't understand anything. Nothing was in context, nothing seemed to make sense. And then sometimes I would be asked for an opinion and I would have to be like, "Um. I don't... Yes?"

Meeri (00:32:57):

And so what I learned was, I think my language learning philosophy in general is just, do it and let it happen. I learn languages by just diving in and hoping for the best. Starting to listen to a Swedish podcast, and then just be like, "If I listen to this enough, I'll understand." And that's my point with this, it's the company and the business language and the field-specific language is just like any other language. And I feel like I'm wasting a lot of my time if I actually start to try to learn it. And instead what I found is, because they can always level down to me, but it's very difficult for me to level up to them, and so what I found was it's more effective to make them speak my language than it is for me to try to speak theirs.

Meeri (00:33:53):

And what I mean by this is one of the biggest things that I found helpful is just repeating back to everything I understood. So I'd be in a meeting and then someone would ask me a question and I would be like, "Okay, well, so from what I heard in this conversation, what I think you're asking me is," and then say what I think I'm supposed to give an opinion to. And then they would be like, "No, a little bit to another direction. A little bit like that. Yes. And then could you also give an opinion to that?"

Meeri (00:34:27):

Or in a situation where someone would be directing or giving me instructions, especially instructions were really difficult to understand, I would just be like, "Okay, I understood that you want me to do," and then say back to them in my language, what I thought they wanted of me. And oftentimes they would come back to me using that same language, the language that I used. And then it's a double good because it establishes this kind of common vocabulary that we're now using in this conversation. It gives me the power to define what kind of vocabulary, what level of specificity we're having in this conversation in terms of language. And then also it clears up a lot of things where I actually didn't understand something, or I did and they thought I didn't. So it's just very effective to make the senior people speak the junior language.

Meeri (00:35:33):

And then the senior language will come with seniority. In every conversation, there will be less need for that kind of guidance. It's kind of, I don't know a better word for it, but it is, in a way, it's guidance because it's me knowingly changing the way they're talking to me. Yes or no questions are really good. It's very good, very effective to ask the senior members yes or no questions. Just be like, "Do you want me to? Should I?" And yeah, it's very good.

Saara (00:36:19):

Thanks, Meeri, I've learned a lot in this because that would help me so much. I'm always learning everyone's, not even professional, but personal language as well, in every situation. I don't know, maybe I'm too kind or too not making my own stance, hardly, but yeah, really good points.

Saara (00:36:50):

And I do think that benefits also the seniors in the team because then they really need to think about... maybe they didn't even understand themselves what they wanted, and then they really needed to think about, "What is it that we want?" Because we do have these languages, okay. Of course, we can use Finnish or English, that doesn't matter, but still it doesn't need to be the professional language because we can explain everything with English.

Meeri (00:37:26):

Yeah. And also, another phenomenon that I found was this very specific type of professional sounding, precise sounding platitudes, where a general idea of like, "Well, you should make it good." Something like that would be expressed instead in very high-level language, in long sentences, and in this kind of squarely type of chains of thought. And then I would get nothing from it because, first of all, I wouldn't understand, and then second of all, the actual substance wouldn't be specific. And so then, repeating back to them what I understood, it'll bring out all of the things that they actually said and those things that they actually didn't say. And so it'll also help get rid of those types of general phrases that are used a lot, and that actually no longer mean anything.

Saara (00:38:29):

Yeah. In those situations, I always ask, "What is the concrete thing that we need to do now? What do we actually need to do now?" Because well, I work a lot with academics and they love to speak with those fancy words and fancy concepts and stuff like that. So, it's still a problem, it doesn't get any easier. But you learn to navigate to it and learn your ways. But you have done excellent job already to figure out how to get them speak like you, understand, everything.

Meeri (00:39:14):

And oftentimes I would find myself asking questions like, "Okay, where do you want me to click?" It's also a problem because things that are so very obvious to more senior members are so very not obvious to me. And then they would be like, "Okay, just make a ticket of it." And I'd be like, "Does that mean Jira? What's the button that I need to click? Which one of these options? What sprint? What does it mean, Add to Sprint? It's giving me a warning. Should I do it?"

Saara (00:39:50):

Yeah. I think manual testing is a great way to start your career because it helps a lot with this kind of communication things and it helps with test automation too. If you know how to communicate in manual testing, I think it really does help.

Meeri (00:40:12):

Yeah.

Lauri (00:40:15):

You talked about repeating their own words in their own language and then establish your own language. There's a wonderful writer, Chris Voss, who is known for being a hostage negotiator, who then turned the skill of doing hostage negotiation into negotiation skills. And something that I remember from him was to basically repeat the words that the other party says.

Lauri (00:40:42):

And so for instance, somebody comes to you and says, "I need you to run me a test." And then you just say, "You want me to run you a test?" And then they say, "Yes, there's this new application that nobody has built tests for." And then you say, "The new application nobody has built a test for?" And they say, "Yeah, yeah. It's like, they developed it last week and nobody got time to do everything. So you have to do X, Y, and Z." And then you say, "I have to do X, Y, and Z?"

Lauri (00:41:09):

And it sounds so naive and so, I don't know, stupid, but you are not giving anything away, you're simply helping the other one articulate exactly what is it that they want. And then, so have a look at Chris Voss. I think he's known for Black Swan, I think it's their company, but they wrote a book and Never Split the Difference which could be worthwhile reading.

Meeri (00:41:33):

Yeah. I think I really relate to that, helping them articulate. Many were the conversations where I just felt like I was just, "My function in this conversation is to help the other people say what they're actually trying to say in a way that I can use it." It maybe even a little bit of a culture clash, I think, trying to speak as a very junior to a very senior member or a doer of anything. And so a lot of times they would be saying what they think is just a normal sentence. And then I would spend 15 sentences trying to get them to articulate what they're actually saying.

Lauri (00:42:16):

Yeah. Well, moving to the third, the last. You call it, very succinctly, "Learn your strengths."

Meeri (00:42:26):

Yeah. I did a lot of kind of soul searching during the summer. Well, I'm kind of philosophically opposed to calling it soul searching because it's from a paid job, but it was very useful for me to think about things that I noticed that I was actually good at and then specifically word them to myself to be able to actually articulate them. So that helps with seeing my place in this organization and in the team and then kind of seeing what I can contribute. And then in that way, it also helps seeing what the other people in the team can help me with. Also, I feel like it helps give a little bit of a deeper meaning to everything I do because then it allows me to, more specifically, take on challenges that I know will be up to what I actually can do.

Meeri (00:43:49):

And so when I'm articulate to myself about what I think I'm good at, then I'm more able to take on more interesting jobs or things to do, or more responsibility in some areas. And then also, it's easier to ask for help in other areas when I know that this is why I need help for with this, and then I'm also able to formulate those questions and start those conversations in a more specific way when I'll be like, "Okay, I know this part of that. I know these aspects of this question, but then I don't know the technicalities." Or, "I know the technicalities, but then I'm having a hard time grasping what's the meaning of this." Or like, "What's the bigger picture of what I'm actually doing?" So yeah, being able to tell myself what I can and cannot do, it became easier to see a lot of... or word a lot of complex situations.

Saara (00:44:59):

Yeah. And in the beginning, I think, you might think that you can't do anything, but I would say that in the beginning, just go for it and then just ask questions and ask for help. They will help you, they want you to be there and they do want to support you. So I would say, even though the task seems impossible at the beginning, you just need to maybe jump in it and go straightforward and just try to figure it out because in the beginning it might seem that you don't know anything. Because at least for me, it did.

Saara (00:45:40):

And I would say that learn your strength is like an aspect you need to come back to. For me, every six months I need to reevaluate what I know and what I don't know and what is really the thing that makes me good in my job and what skills I lack of, and how can I develop those skills or do I even want to? Does they interest me that much? and stuff like that. So I would say that aspect, you do need to come across many times during your career. So that's a good thing that you thought about it in the earlier stages as well. Because I didn't, I was like, "I don't know anything. I'm just bad at everything." So I didn't even think that I had strengths. So it's super healthy-

Meeri (00:46:50):

Well, to be fair, the things that I consider being my strengths are things like making friends.

Saara (00:46:57):

But that's super good. That's a strength that it's harder to learn. You can always learn how to do a certain code or do technical stuff. So I think that's a harder thing to learn, so I think kudos for that.

Meeri (00:47:21):

Yeah. Should I write that on my CV?

Saara (00:47:24):

Yeah.

Meeri (00:47:24):

Like the skills...Python, test automation, making friends.

Saara (00:47:28):

Yeah.

Lauri (00:47:30):

I assume that what you are sharing is not unique to you in that you have to reflect, you have to find the strengths and that people are in different stages in that journey. And yet companies are hiring a lot of people all the time. My question would be, do you have a message that you would be sending to hiring managers so that they could better take this into account when they're hiring people, especially people early in their career?

Meeri (00:48:04):

I think what I would like more from hiring managers and from the hiring process is a more precise articulation of, "What is going to be your role in this company or what is going to be your role in this team?" And then this would... Being able to kind of... And I recognize that a lot of times, especially junior hires won't have a specifically preset role. It's like when they hired me, they were like, "Yeah, it depends on the person who we hire, what they're going to be doing."

Meeri (00:48:46):

But I would like there to be some type of consideration for, "What we're looking for in this hire." Not just as in like, "We're looking for someone who knows this and knows that and can do that," because that, they're very good at articulating. There are very long lists of things we want you to know. More of a description of, "What this team is. What we do as a big thing. What we would like? Why we're hiring a junior member?" is a big question that usually isn't answered.

Meeri (00:49:31):

It's just like, "Are you doing charity?" Probably not. There's a reason that you're hiring a novice. There's a reason that you're hiring a summer trainee. And I would like that reason to be articulated because if I get that, then I'm better able to judge if I would like this job, if I would be useful for this job. And then I would also be able to bring out the right things about me, if I do think that I'd be a good fit. That's what I would like.

Saara (00:50:07):

Yeah. Totally agree with every word. There's super long lists with technical things that you need to know, but not like... I would say that it would be great that the hiring managers would see past those and just see that are you a good fit to the team, and stuff like that. Because you're a novice, you don't have much. You have something that you touched upon in school. And you maybe don't even remember that you know that program. In my case, I didn't even remember some... and I was like, "Oh, yeah. I do know this. I have done this." But I didn't see that as my strength or as my knowledge at the time.

Meeri (00:50:57):

Yeah.

Lauri (00:50:59):

Super two remaining. Number six, "A big part of your value for the team you work with comes from your adaptability."

Meeri (00:51:08):

Yeah. I think that's a reminder for myself, is that the reason I'm the junior member of the... or a part of my value is being the junior member of the team. There is something kind of inherently flexible or adaptable about being the least knowledgeable or the least experienced. There's a lot of previous old beliefs and experiences and ideas that a lot of senior people have that can interfere with some... especially maybe noticing general patterns and just more of these type of like what we talked about before, where there's a lot of this general consensus of, "This is how this works." And then when you kind of scratch it, then you find out that, well, maybe it shouldn't work that way or that doesn't actually work that way, and we just think it does. And a lot of times you might need a new brain to actually notice those things.

Lauri (00:52:25):

We remind the new people about that, now that you are still young to the team. And then you cease to be young to the team, maybe at something like six-month or nine-month point. But imagine if we all could maintain that freshness of the gaze at all times, and we could all think, "Now that I'm still new to the team," even though we would have been there for years, I think would be highly valuable for everyone.

Meeri (00:52:59):

And of course, I do think that there's a lot of value to the experience and insight that people have. Even specifically in a certain team, it's important to have members that really know how things have worked for a long time and kind of have that history with those processes. But there are situations where it can be valuable to not have that kind of background.

Saara (00:53:27):

Mm-hmm (affirmative). There's a lot of baggage in the seniority. It comes with the baggage, usually. And that's why I think a consultant job is quite great because you're usually quite junior in the new company where you're working for, in your customer. So I think that's the best part of my job at least, to be-

Meeri (00:53:55):

Consultants are like professional juniors.

Saara (00:54:01):

Yeah. Yeah. That's a great way to put it.

Lauri (00:54:02):

Yeah. That's a good point of view. I haven't thought about it that way. You have the seniority without the heritage, or without the legacy, rather.

Saara (00:54:11):

Yeah. You don't have the bad baggage or good baggage, but still baggage.

Lauri (00:54:18):

Yeah. Which takes us to the last point, and I'm sure that this applies also for senior people, which is, "To take a lot of notes."

Meeri (00:54:31):

Yeah. What I regret most is not taking notes of every conversation I had with, actually, anyone. It's so easy to remember the big ideas that were presented to you, the kind of generalities. But then when you actually start doing something, then you wish that you could go back to that conversation and remember the specifics of what you were discussing, especially in situations where I was given advice or instructions or help, and would just be like, "Yeah, I remember, I remember, I remember. Okay. Okay. I understood." And then I go back to my work and I'm like, "Okay. What I actually remember is you should make it work. Um, thanks, brain."

Meeri (00:55:28):

And then when I learned to actually take notes of things that were told to me, it became so much easier. And then I would have a problem, I'd be like, "Oh, I've seen this before. And I remember having a conversation about this, and I remember having it solved, but I don't remember how." And now when I had notes of that, I could just go back to the notes and be like, "Oh, this is how it was solved." And then when I didn't have notes, I would have to go back to that same person and be like, "Hi, I remember we had this conversation. I don't remember what you said, but I remember that you said something and it helped." And so notes are crucial to not wasting everyone else's time oftentimes, not having to have the same conversations, always, all the time, with the same people.

Saara (00:56:16):

Yeah. I would say notes and then good project management systems, like creating tickets and possibly creating them in a good way that everybody understands what needs to be done and what are the concrete tasks.

Meeri (00:56:34):

Oh yeah.

Saara (00:56:35):

I do agree, notes are super great. I've done lots of notes during my career, at least.

Meeri (00:56:40):

Yeah. I remember times when a ticket was assigned to me by someone else and I would notice that it's assigned to me and I would read it and I would not understand what was wanted. I would read the text and I would know what it means, but then the ticket would have no sense of what I needed to actually do. I would just be there like, "Okay." And then I would have to go to the actual person, making the ticket and be like, "What do you want of me, with this?" And then it usually would be explained in a team's chat. So it's just text, the text could have been put in the ticket, but it wasn't, and then I would have to just ask for a lot of clarification.

Saara (00:57:28):

That's why it's good to keep these retrospectives and look at your sprint that, how did it go, and how was the requirements? At least in my job, we have always discussed that during the sprints and well, sometimes they're bad, sometimes they're good, and sometimes we do improve them and sometimes maybe not. But still, it's good to keep in mind.

Saara (00:57:55):

I would say in addition to notes, also do what's best for you. If you're now listening and you're like, "Oh, frick, I hate notes. I can't do notes," then just do what's the best way for you to learn. If it's having 75 tabs open to your browser, I do not recommend, but I have seen this a lot and I have done this a lot to myself also. I would say that maybe the better way is to put them in your bookmarks or something like that, not keeping them always open because that mix up your brain a little bit, at least in my opinion.

Saara (00:58:36):

But yeah, there's a lot of, again, these open source tools and communities that if you do have the courage just turn in and see how it goes, how the people are there, and there you can ask maybe a little bit more technical questions.

Lauri (00:58:56):

I know I'm probably representing minority of the opinions here, but I still take notes, handwritten. And I believe in the hypothesis that when you listen to something and you absorb it, and then you explain that in your own words, whatever is it that you're writing down will be structured in a different way when you write it in your own words, as opposed to listening to somebody and being really good at speed writing.

Saara (00:59:25):

Mm-hmm (affirmative). Yeah, I do handwritten.

Meeri (00:59:28):

Same.

Saara (00:59:31):

Yeah. Same here. And I did have a calendar, the Real Deal book calendar in forever, and then everybody was like, "You're crazy."

Meeri (00:59:46):

Yeah. I use a bullet journal because I get anxious about having empty pages in my calendar. So I use a bullet journal where I can just have all my things. I can just always start on a new page. The reason that I take handwritten notes, for example in lectures, is because I hate typos and you can't make typos when you're handwriting. And so I feel like it's often, it's actually faster for me to take handwriting notes because I don't have to go back and fix things. And then also I have to be more concise because it's slower, the writing speed is slower. So I have to be more articulate and specific. But then also I don't have to worry about typos.

Lauri (01:00:38):

This was lovely conversation, thank you very much for both of you, Meeri and Saara. I'm confident that this will be helpful for a lot of specialists, novice, and not-novice anymore on test automation or in general, all things software development. So thanks again for joining our podcast.

Saara (01:01:01):

Thank you.

Meeri (01:01:01):

Thank you.

Lauri (01:01:01):

Thank you for listening. If you want to continue the conversation with Meeri and Saara, you can find their social media profiles from the show notes. If you haven't already, please subscribe to our podcast and give us a rating on your platform, it means the world to us. Also, check out other episodes for interesting and exciting talks. Finally, before we sign off, let's give Meeri and Saara an opportunity to introduce themselves. I say, now take care of yourself and keep up testing.

Meeri (01:01:30):

I'm Meeri, and I'm currently studying mathematics and systems engineering at Aalto University. Last summer, I was a systems testing systems trainee for Vaisala in the team of embedded software and systems. I was doing a lot of manual testing and test automation.

Saara (01:01:52):

My name is Saara Laakko. I'm a DevOps consultant in Eficode. I'm specialized in test automation now, and I have a background in manual testing and test automation in embedded testing specifically. I always love to learn more about software testing, software development processes, and also test automation.