Quality Influencer with Parveen Khan

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Parveen Khan all about agile, DevOps, automation testing, all kinds of things. Praveen is a senior quality analyst consultant at ThoughtWorks and being a quality advocate, she really delivers high quality products. She believes it's everyone's responsibility. She also loves collaborating. If you ever visited her blog, you could tell she's really involved in the community. She loves helping teams optimize their process tools and methodology to help enable in creation of high quality products. She's also an international speaker. She shares her stories and experience in testing to inspire other people around the globe. She actually spoke, I believe at the 2018 Test Guild. So really excited to catch up with her. It's been a while. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment for Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out. Hey Parvu. Welcome to the Guild.

Hey. Hello Joe. Yeah, thank you so much for having me. I'm so super excited for be here.

Same. You've been on my list for a while. I don't know why this hasn't happened earlier. So thank you so much for doing this. I appreciate it. And I also just realized looking at your LinkedIn profile, you started a fairly new gig at ThoughtWorks so just curious to know what that's like because ThoughtWorks is like they always come up with really great innovations so I'm just curious to know what it's like to work there.

Yeah, I've just recently joined ThoughtWorks and so far it's been amazing. It's been like really awesome to work with so many like different people who have different thought process and working in so much kind of like modern culture I can say where like you know I really thoroughly enjoying so far being here at thoughtworks like and it's been six months so far and it's like day to day learning. It's kind of like so many people out there where you can just learn from everybody. So yeah it's been going pretty well and enjoying it so far.

Nice. Any tips for People starting a new career or a new job, how maybe to make that transition, to make that learning, learning fun and not stressful? I guess.

Yeah. I think for me when I was taking up this decision of moving into a job during this remote world, I was pretty scary. Like, you know, because you don't get to meet people and changing the job because you don't. I used to believe in like you need to build the relations, you need to meet the people, get into the office and you can settle into the team and try to work together. But since I've joined, of course I've met people, my team members, people from ThoughtWorks and everywhere, everyone. But I think it's been so amazing that doesn't matter whether it's remote or whether it's in person, the amount of effort or so it's like technology. Like you know, the world with technology you still have, you still can feel the connect, you can still have the same thought process of building the relations while you're remote. So I think we don't have to get scared. I think that was my first thing. So that's why I started talking about this because I was very scared to make that transition. Like I don't know how because for me building the relations is the most important thing when I try to think of working with within the team. So I used to feel like if I'm working remotely then how am I supposed to do that? Like you know, But I think you don't have to be scared even if it is remote or in person doesn't matter. Like you know, as long as you know you have joined the right team, like right company where there's a culture of being remote doesn't limit and you don't have to be scared about that. I think that's the only one thing living in this sort of like, like this sort of world. I think that's what I would be my first advice that don't be scared that you have to join a new company or a new team during this pandemic. Sit like you know, during the remote world.

Awesome. So now when we talked in 2018, you had a unique experience where you made a transition over to Agile. So I want to like go on a little journey like you're starting there and then like you said you're working in a Martin place now in ThoughtWorks. I just want to see what the difference is. So let's start from the beginning, you know, for actually I don't know how many people haven't, haven't already switched for Agile. For the people that haven't though, can you just tell me a little bit more about your story of maybe how you got into agile and how people like me maybe were in waterfall before and it was kind of hard to go into more of an agile type of approach.

Yeah, I think going back into those, I remember like delivering this talk of transitioning from waterfall to agile at Automate, like Test Guild, comparing going through that until now, the journey. Now I think I feel like when you're working in waterfall, like I know I worked in the water Polish model where like I used to sit at the end of the tunnel where you get to see what you need to test towards the end. And you were kind of a solo team on your own, without any interaction or without feeling or adding any value. You were kind of like your own solo, solo team as a tester. So then with the same team we transition into agile. So that's where I shared my story. So I think it is so different that you as a tester, like for me, like that's what I have learned and that's how I felt. And you feel like you are part of the whole entire team and you're part of every step in the process. You get to add the value, you get to share your opinions and you not somewhere just like a gatekeeper or towards the end, just chuck the work on you and test it and that's it, you're there just as a tester, like, yeah, I say just as a tester because it's not just testing and getting things done, but I think now it's more of being the quality champion, being the quality advocate. I think that's exactly what I like and that's where the difference is. When I say modern culture, it's like not trying to chuck the work on you and say that this is what you have to do, test it, get it done. But it's more about being involved throughout because there's so much to do, right. It's not that towards the end shifting left, shifting right through continuous cycle. Like, you know, you are everywhere, like as a tester. So I think there's a huge difference how things have changed now. Or that's why I kind of said, when I said working in a modern.

Culture, I love that quote, you are everywhere as a tester now. A lot of times testers come to me say, oh, am I going to be out of a job? But like from my experience and from your experience it sounds like no way. Because it's almost like you've been elevated, like A quality advocate, you're all over the place. And how do people get done without having that someone there that that's able to champion some of these things? For sure. Are you seeing the same thing then?

Yeah.

That you know, you're involved now in things maybe you would have thought back in the day, oh, I'm just a tester. I'm not involved in planning that, that type of activity.

Yeah, absolutely. And I think it's like nowhere. Tester's job is not going anywhere. Like no matter what new technology or tool comes in. Because that human side of thing, that creative thinking or I can say that's the reason why I say advocating about the quality. Yet like you have to make people think about quality. Even though we say that whole team owns like nowadays talk about this, right? Like it's not just testers who own the quality, but the whole team, Entire team owns the quality. But I think you have to be there as a quality champion to keep reminding and to keep looking at the, trying to look at the different things that needs to be improved on the product and try. It's not about you doing the things, it doesn't have to be that. But being a tester, I think you have to look out for different risks. What are the different risks that product has or what are the different things that you need to add based on what kind of product you're working? So I think these are the things which you being a tester, you have to keep influencing the team to do these kind of things. And it doesn't have to be like you have to be an expert on every tool that's out there and do the things by yourself to build the quality of the product. So I think that's how I see it.

You know, once again that really resonates with me. I'm reading a book, who not how. And actually I didn't even thought about it until now just to mention that how it actually applies to testers as well. That a lot of times as testers we think we need to do everything, we need to be hands on everything. But now it's almost like, okay, I don't have to know that. I just need to know why it's important and then find the who to do it. I think that's critical and that's a great, great point for sure. How do you get people to, to then do that for you? Then if you, if you say you know, you notice, wow, this is, we're lacking here. I don't know how to do it, but we know we need to know how to do it. You should do it. How do you, like, get that going?

Yeah, again, that's not something like that's going to happen within a day or a two or a month or two. But it takes a lot of trust and collaboration within the team to show that. Why? Like, I can't just go to my developer and say that, look, we have to do, for example, like, we have to do this automated access testing, so can you use this tool and just do that for me? So I can't say that. That's not how. So I think building that trust, building that relation and then trying to say why and how. Why am I doing, like, if I'm proposing something, what is it? How is it that adds value and what am I trying to eliminate? So I think giving out those points and trying to. And again, I think the thing which works most for me, that has worked for me so far, it's like not just saying that let's do this and get away with it, but just trying to say like, let's this together, let's pair. So I'll be the person who's looking at like, for example, if I'm pairing with my team, with my developers, I won't be like, you just go and do the, use this tool and do the magic behind the scene and just tell me how it's doing. But it's more of like, let's do this together and these, let's look at these things. And I think it's about pairing and doing things together. I think that's how things have worked for me and showing why I'm doing that, so that now they understand that the reason why I'm asking them to pair or asking my developers to do that is because they want me to do the most important, like the most critical thing, which is exploring the product and coming up with the. Learning about the product and coming up with any issues or edge cases or trying to come up with those things. So I think that's where the point comes in when you slowly try to build that trust and get work together, I think that definitely will if you slowly try to build. So I think that's how it has worked for me so far.

Absolutely. I know in your session back in 2018, you talked about, you had four points. One of them was planning, the other was collaboration. So it sounds like peering is kind of falls into the collaboration bucket almost regardless of what you're doing. So that's awesome.

Yeah.

So I guess my other question is you also practice what you Preach. I want you a blog and I think you have something observability for testers. And a lot of times when people hear observability, they think, oh, that's like the SRE team, the performance team. So I'd love to. It's been such a hot topic this year. I'd love to get your opinion on what is observability and then like how you start as being critical and how you think testers can be involved in it.

Oh, yeah, that's. That's one of my favorite topic.

Oh, good, Cool.

Yeah. So I think there's again, again thinking as when I say thinking as a tester, like, you know, it's not. We always think about quality, we always think about improving the quality. So it doesn't have to be limited to just that testing world where, oh, we have to improve the test automation, we have to improve this and that. But it has to be everywhere, right? So I think that's how I think. And observability is more about making sure your, your product has visibility so that whenever things go wrong, you know how to look. It's not about, you know where to look, because production issues, it might be anywhere it might be. So you cannot always predict how users are doing things or you cannot always predict the production bugs. Right. Any issues on the production, they are always something new or they are always unknown. So I think we cannot stop the failures, but we can be prepared for finding out how and what has caused those failures. So I think when things go wrong, you cannot expect that. Oh, let me just try to. Can I get some information? I think you have to think about building that visibility throughout so that then you are prepared when and what you have to look for. I think being testers, I feel like because we explore the product so much, we are explorers, we ask questions. So that's how I feel like when we are exploring, we have to look for those adding value. Like, you know, looking at those logs, are they giving us enough information or not? Those little things, things we can always work, you know, work with the devs or whoever is implementing those logs and improve the visibility. I think we as testers can always add value to that. It's not about SREs, it's not about devs, or it's not about anything as such. Like, you know, it's about how as a tester you can improve the visibility of the system. Again, coming back to the. You don't have to implement, you can always look at different things like, you know, and then add value as a Tester saying that okay, when I'm testing this or when I'm exploring this particular feature, I don't see enough information or in the logs or it doesn't explain well. So these are little things, little steps which you can always help the team to build that observability within your team or on your services or on your product.

I think so I guess for someone that is maybe new to observability. How would you explain what observability is?

Yeah, I remember when I came across this term, I think Abby Bangs was the first from home I came across this term and that's where I started to look. I used to question myself like okay, visibility is fine, but how. What, like what kind of visibility. I know that it's. When you come across this, it's hard, you just don't understand. It's very hard when you just read across. Come across those blogs or like it's theory still. It's very theory in your head and you cannot make sense out of it. At least I couldn't make sense out of it. But I think I was lucky enough that I was working on. I think this is where I shared my story of how I learned about observability I was working on with one of the team. I think when you are trying to read and then when you relate to those stuff within your work, I think that's where at least I understand things well, tell at least how and I understood about observability. Anyone who is new, I think who wants to learn or who is exploring this particular topic, only thing I would say is talking to your team and coming up with this terminology and going to them and asking like okay, what kind of tools? I'm sure most of us might be using these tools of how we access the traces or logs or anything on your services or your product. But I think just trying to have these conversations with the devs and trying to see what tools do we have and how. And I think that's where it might, might help when you read and look actually how things are working. I think that's where you will understand a bit more instead of just looking at the theory. And I think one thing I've also tried was like these free trial tools outside there and some of the. The real world apps outside there and trying to connect together and see how this instrumentation works and why and what it does. You don't have to do everything you know, understand, but it's like simple things. Trying to send some requests using the free. At least like those trial Version of tools and then seeing how those requests, you can see the visibility of those requests within those tools. And then I think you can connect to the things what those blogs or things are talking about, especially about this topic. I think that's how I have tried to understand this actually working on those tools, using those tools.

I love that approach. It's almost like a proof of concept. So I assume like once you got something working, you go to your team, hey look, look what I did just with these free tools. Maybe we should invest a little more time and money into it. Usually it works.

Yeah, yeah, that's exactly how it works. And I think I've just tried to use those. Having some knowledge sharing sessions at your work, it could be lunch and learn any kind of knowledge sharing sessions where you can share about this. I think that's how I've tried in my previous team where like I came across this and I tried. It's not about learning everything, mastering everything and then sharing with the team. But once you understand that I've shared with my team and that's where they were like, oh yeah, this is something we have to. We could look at because that's what I think that is exactly what is missing within our team. But we don't know how and what so. But at least you've influenced enough that those topic at least people are talking about observability and trying to find different ways. So at least you have sowed the seed. So I think that's how it kind of worked.

How do you do that when you work remotely? Like a set time where people do a share or is it just you just contact people? Hey, I just want to show you something like how does that work?

Yeah, I think we kind of had a bi weekly, like once a month or once in two weeks we had a set time where we used to meet the whole team members and everyone would come. If anyone wants to share about some topic, they would. The trick was because I wanted to knowledge share. What I did was okay, let's have a lunch and learn sessions, let's do some knowledge sharing. And then people would put some topics in and every week someone would share about something. And that's how it kind of worked. Because again, even if everyone doesn't attend, if doesn't join those sessions, at least some people are there and it's good to. I think that's one of the way during this remote world, one of not just working and not just work related meetings, but at least you have something different where you can talk about any Topic it's not about just presentation every time but we can always have like Lean coffee style topic discussion about the topic. And so I think this is how we had done in the past like in the, in my previous team.

Nice. Now when you were talking about observability tools, you say you tried a bunch of different free trials. Are there any tools you really enjoyed or any tools you recommend for people? Maybe again their feet wet if they're just like oh I want to try this out but I don't know where to start.

I've tried a bunch of them. So it was to start with, I think I've tried with Kibana and Honeycomb. I think these were the initial tools that I have tried just to get my hands on like and see what they look like. So I would say yeah, I can share the links but these are my initial top of my head that these are the things which I've tried.

Nice. So can you just tell me like what's the workflow now for you at ThoughtWorks? Because I know you know when you worked before was is it the same agile type of approach? Is it more like a devopsy type of approach? Is it any different? Just curious know like as a tester, your day to day kind of workflow in your organization.

Yeah, again I think it definitely depends on team to team where you are placed on but I think it's mostly it's the same like mixed of agile and DevOps or mixed where depending on what project you're working on. It's either it's doing the continuous delivery or and it is definitely to do with the whole agile way of working where you have, you kind of involve everyone, collaborate with everyone and again it's like you know, one size doesn't fit all kind of a thing. It's not like there are set of set of processes out there and then you have to follow this and you have to just work based on this. It's not something like that again it's about which the context of the product and the team and the project you're on. So that's how we kind of process ourselves and work. So it's more of a collaborative approach and I think being a qa, I think it's more of like you know, being, being a consultant, being a quality advocate and making sure we think about it and how we think and what are the things we have to look for right now.

I haven't been on a job interview in forever so I'm just curious to know since you did recently change jobs. And a lot of people always ask us like what kind of interview questions should I expect? Was there anything that threw you off? I never thought I should know about that.

Or I think again one thing I would say is I don't know how many different companies would do differently. But I think as long as you have a story to tell about what you work on a day to day basis and you know what you have worked on, I think personally this is what I have done so far. It's like even though the interview questions are more like, you know, what is this? What is that? You can always add your story of how you have done that. It's not about just answering, okay, if someone asks you why would you use this tool or what is exploratory testing or how would you do that or how would you influence your team? So instead of saying that this is how you should be doing, I think I've always approached in a way that tell my story of what I have tried. Even though I have not tried the exact topic, but I might have something else like an example. I've not tried this, but have tried something else. And this is my story behind it and this is how I have tried it. So I think we all, all have worked and if we are going for an interview all we all have a story to tell about what we have done on a day to day basis. So I think that would be my one advice for anyone who is interviewing now. Just tell, just share your story of what you have done, your experiences, your challenges. It's not about you showing all your success stories there. Even if you have tried something and it didn't work, I think even that's that will show that you have, you have that courage to try something and you have that courage to share your failure. So I think that's how I see it. It does.

Great. Love that. Also on your website says something about a testing tour. What is a testing tour?

Yeah, I was on a testing Tour. Yeah, in 2019 and I think that's where I started that blog post and sharing my tour. So I think I got inspired by Lissy Hawk because I attended my one of the conference talk in 2019 and there was a talk about testing tour and I was so inspired and I took away that, okay, every time I say I'm inspired, tired, that's not enough. I should be doing something out of that inspiration. Right? I need to do something. So I think that's where I thought, okay, I want to do the similar thing. I want to go on A testing tour. But I didn't knew enough people. I was scared that people might not pair with me. I was scared that I might not be able to do it everything. So being on that testing tour, it was such an awesome experience for me. It was a journey and I've learned a lot out of that. It's not about just learning about the topic, but it's also learning about my own self because I was very scared before going there. But to come back to your question, what exactly testing Tour is? It is about going on a tour, picking up topics, pairing with different people and learning about those topics. So it's like when you go on a tour you visit different places and visit different places. So similarly for this testing tour it was more about pairing with different people on different topic and together learning about that topic. And then I used to write a blog post about it and share it. This is what I have done during this testing tour.

It's a great idea. I'll actually have a link to that the show notes for folks to definitely check it out on your blog. Okay Parveen, before we go, is there one piece of actual advice you can give to someone to help them with their testing efforts and what's the best way to find or contact you?

Yeah, I'm out there on Twitter and I am on LinkedIn and you can always reach me out and feel free to reach me out if you want to have a chat, if you want to ask me anything or if you want to share something about anything, feel free to reach me out. And one piece of advice before I leave would be like yes, you don't have to. Don't worry, don't be scared or don't worry about like whether your role is going to be there or not or as a tester, manual testing, automation, testing, AI. Nothing is going to stop us. We have to always be there and you don't have to learn every tool out there to proceed in your career. You can always be a quality influencer. You don't have to do everything but you can always influence about quality. And yeah, don't be scared, don't be worried that testers job are going to be taken away or anything as such. So that would be my one piece of advice for everyone listening to me.

Thanks again for your automation awesomeness. The links to evident value we covered in this episode head on over to testguild.com forward/a379 and while you're there make sure to click on the try for free today link under the exclusive sponsor section to learn all about Sauce Lab's awesome products and services. And if the show has helped you in any way, why not write rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to test guild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.