Show notes
About the guest:Parveen is a UK-based senior quality analyst consultant at Thoughtworks. Being a quality advocate, she believes delivering high-quality products is everyone's responsibility. She loves collaborating with teams and optimizing processes, tools and methodologies to enable the creation of high-quality products. She is also an international speaker sharing her stories and experiences in testing to inspire other people around the globe. In her spare time, she plays the role of wonder woman for her two lovely kids. Find our guest on:Parveen's TwitterParveen's LinkedInParveen's BlogFind us on:On Call Me Maybe Podcast TwitterOn Call Me Maybe Podcast LinkedIn PageAdriana’s TwitterAdriana’s LinkedInAdriana’s InstagramAna’s TwitterAna’s LinkedInAna's InstagramShow Links:ThoughtworksExploratory TestingAdditional Links:Blog Post: Observability for TestersBlog Post: Why Observability Matters for TestersO11ycast Podcast: Ep. 26, Unknown Unknowns with Parveen Khan of Square Marble TechnologyParveen’s Speaking EngagementsTranscript:ADRIANA: Hey, everyone. Welcome to On-Call Me Maybe. I am your host, Adriana Villela. And with me, I have Ana. I'll let Ana introduce herself.ANA: Hi, y'all. My name is Ana Margarita Medina, and I'm very excited. We're going to have an amazing episode today. So I'll switch it on back to our co-host, Adriana.ADRIANA: Today with us, we have Parveen. I'll let Parveen introduce herself. Why don't you tell us a little bit about yourself and also how we connected, how we found each other.PARVEEN: Yeah. Hello. So I'm Parveen Khan, and I'm a senior QA consultant at Thoughtworks. Yeah, I kind of work as a quality advocate, all about quality with the teams. And also, I share my learning experiences across trying to speak at different conferences and writing blog posts. And I share some of my thoughts being on a podcast. I'm super excited to be here today. So I still remember such a simple conversation, like, I think I read a blog post about observability myths. So that's where I think I thought, okay, this is so cool. It's such an easy way to explain all this all-around observability. Because I know there are a lot of different blog posts available, a lot of resources there. But then I think when I read that blog post, I was so fascinated that I think I reached out to Adriana just on LinkedIn, saying that, "Oh, this is so cool. You've given such great information out there in such a simple way so that everyone can understand." So I think that's how we kind of met.ADRIANA: Yeah, totally. And I love that we were able to connect through LinkedIn. And it's funny because you're not the first person that I've connected with through LinkedIn because of the blog posts that I've written. So I really appreciate it when people reach out to want to chat about these types of things. And I'm super stoked that the blog posts on observability resonated with you. And after you reached out, we booked a meeting to talk about observability and QA. And you sent me on this whole, like; you opened my mind to this whole new way of looking at observability and QA. Maybe why don't you talk a little bit about how you started applying observability as part of your role?PARVEEN: For me, I think it was never like, okay, this is what observability is, and this is how you can use it, and this is how I can try to make use of it as a QA; it was never like that. So I think it was a way of me trying to learn different challenges at work. I remember I was working with one of the teams. And I came across a lot of challenges, which I was unsure of why these things are happening. We kind of had no information at all. It was interesting, like, I was just trying to read a lot about observability at that point of time.I just came across this new term observability and then how it kind of connected between...sometimes it's like you cannot understand when to use it until you are in that situation. So I think for me, it was more of like I was in that situation where I realized that, okay, this is the reason why we need observability. So I think that's where my learnings and my understanding started from, and then that's where I started to learn a little bit more about it. Because I think for me, initially, it was more of like, okay, this has nothing to do with me. I don't know if this is something as a QA I can make use of it, or I can try something on it. But I think the more I tried to learn and explore more about it and found those challenges on the product that I was working on; I think that's where it opened up a lot of possibilities for me, okay, I think this is how I can use this being a QA, and this is how I can try to add some value from a QA perspective. So I think it started in that sense for me.ADRIANA: That's so cool. And I think it's interesting, too, when you talk about trying to understand what observability is because I don't know about you, and maybe Ana, maybe you can relate to this as well. Like, when I first heard the term observability, and it was, I would say at least like two years ago, I swear to God it took me so long to wrap my head around what it was. I don't get it; I don't get it. I feel like it's something that's important, something really cool that we need, but I don't get it. And all the definitions were so academic, and I'm like, ah, what the hell is this thing?ANA: I can relate 10,000% about everything that was just said in the last few minutes. Because as Parveen was saying, that part about learning you hear a word and you're just like, what is this? This sounds interesting. Let me go research and see how this ties into the world as I know it and what you kind of call a mental model. And then you start asking more questions, and you're like, oh, idea, now this all starts clicking. And that's what a lot of DevOps means to me, in my opinion.You hear the word DevOps; you have to kind of come together, and it's like, dev, ops, collaboration, communication, tada, we have amazing things. And with observability, I felt like that's a lot of what the space has brought. For me, I have that similar experience where I heard the word, and I was like, this means nothing to me; move the page, keep on going. I come from chaos engineering, like; that was my introduction to systems, chaos engineering infrastructure. And I was working at Uber during that time, and we had Jaeger. So I started learning about tracing without knowing anything about observability. And I was like, we had our internal tool for metrics, and we had M3 and Jaeger. And then all of a sudden, I was like, I like dashboards. These things [laughs] make a lot more sense. I come from a perspective where I was like, I understand observability to the point that I need to, but I don't need to dive into it. And then I'm coming back to the table four or five years wiser. And it's like, oh, actually, the more we know of our system, the better we're able to understand the system that it engages with on a day-to-day basis of our users. And what happens internally is when we have our very complex architectures of like system 1 calls database number 20 but then goes back to database 1, what happened in this time span of five seconds? [laughs]ADRIANA: Yeah, totally, totally. And for me, it was like this, oh, I get a holistic view of my system? Because from my personal experience, I remember back in the day, even seven years ago, I remember I was helping troubleshoot an application. It was a vendor application that we had running in prod, and it was slow. I talked to the database person, and they're like, "No, the database is performing fine." I talked to the network person, "No, network is performing fine, hard drive's performing fine." I'm like, "Guys, something's not working, [laughs] but everyone says that their thing is running fine. What the hell is going on?"And I feel like observability unlocks this new level, expert level where all of a sudden you're like, oh my God, finally. I can find that little needle in the haystack. I have that visibility into the thing that's not working for me properly. Parveen, when you and I were chatting initially, that was part of the aha moment for you. As a QA tester, you're like, oh, I know what's wrong.PARVEEN: [laughs] Yeah, exactly. I think it's about figuring out how to know where things are wrong. It gives you the ability to look for some more information, look for trying like, okay, it's not about just saying...so as a QA, when you just go to the developer and say, "Oh, something is broken," it doesn't give you anything. Okay, something is broken, but what exactly is broken? So I think as a QA, I'll be in a better position to give a bit more details around what are the things happening behind like, you know, what has broken. So it's not like me giving the solution of oh, here's the thing that is broken, but trying to give more information around okay, I've observed these kinds of things, or I have noticed these things when I was trying to see where something has been broken. So I think it's about trying to help navigate or trying to give a bit more information to the developers.ADRIANA: Yeah, totally. When you and I chatted...I had a role as a QA tester early in my career. And I remember when I was testing, I'm like, it's broken, but I don't know why. And I'm like, I don't want to just sit here until the developers figure out what the hell's going on to find out what the problem is. I want in. I want to figure out if there's something I can do to find the problems. So I wish that observability had been as mature as it is now 20 years ago when I started my career. That would have been so awesome. [laughs]ANA: I have a similar experience of being put in a QA position where just like, here are the screenshots, here are the steps I took. Here's what didn't happen. Oh, you won't get back to me for another week? Yeah, let me try to recap all my notes when you do get back to me on why it was pink and not blue. I don't know [laughs] what to tell you; the system just didn't handle it properly. So I think the more that we're able to know the right information at the right moment, it's also critical. It is not just about knowing this information. Because when we talk about having to fix something when it really matters, like being in those moments of your customer is reeling bad, how do you make sure that we can get them the most assistance? Or we're really close to launch; how do we make sure that we finish the backlog of your tickets? So yeah, that moment where it's like, oh, it's crunch time. Why didn't this work? Why is Bobby mad at me right now? And why is my supervisor, Veronica, still questioning, like, "Hey, why don't we have this case closed in so long?" It's really getting that context when you really need it.ADRIANA: Yeah, I totally agree. And it doesn't apply just to the pre-prod QA, either. I mean, we're basically testing when we're in prod every day because our users are always finding new and interesting ways of using our systems in ways that, as a developer, you're like, oh, I didn't even think that that could be done that way, so you get the insights both in the pre-prod and the post-prod, I guess, areas for your system. And that makes it very valuable on both ends. And I think having the additional insights in the pre-prod stages won't make a perfect product, but it will certainly help to get rid of some of the wrinkles before you go into production, which I think is awesome.PARVEEN: Yeah, it's more of like, you can learn from the production system because that's where the actual things happen. That's where our users are using our features. I think it helps us in trying to understand not just how our systems are behaving in the production system but also how our users are using our production system. And then using that as feedback and trying to add that into our process. And then I like to say this, like; you cannot shift right until you shift left. You have to shift your mindset to the left and try to think. That's why I like to say that observability is more like a mindset change. And it's more of like; you try to think whenever you're releasing the feature to production, it's not about keeping your fingers crossed and saying that "Oh, I hope everything goes well." It's about asking those questions beforehand and saying, "Okay, if I release this feature to production, how would I know something has gone wrong?" Again, I'm not trying to say that observability is rocket science, and you will know everything with it, but still, you are prepared. At least your aim is you don't want to fail. But your aim would be something like, even if you fail, do you know how to get some information about it instead of blindly going around and trying to see, like, I don't know where to go kind of situation, right? ADRIANA: Yeah, totally. It's the idea of it's enabling you to fail fast, right? PARVEEN: Yeah.ANA: Beautifully said. Like, fail fast, get comfortable with failure because if we're not comfortable with failure, you're going to end up having more failures in the moments that matter to your customer or any of your users. And it's a lot of what I've been iterating for the last four years but from a whole different angle of like, the faster your engineering team is able to get comfortable with failure, the easier it's going to be when your pager goes off when that incident gets started because your team already knows what to do. They know, oh, this is how my observability tool works. And hopefully, you're working in an organization that only has one, not like five that you have to be like, [vocalization] was it this one? Or did we migrate this service to our new one? And it's those little things that really add those extra minutes, those extra hours to an incident getting closed or any type of ticket being closed and a customer being happy once again and staying as a return customer with oh, what I came to shop for actually got into the car. I got a tracking code, perfect. Or where is it that it's failing, and how can we make it be better? And as Parveen was saying, very much of injecting it and, like, knowing what's going on the closer on the shift left is the most important. I'm a huge fan of having perfect, ideal world DevOps in an SRE world across all your cycles, but I know that's extremely expensive. So it's like having it in pre-prod and staging; the more context and observability that you have, the more comfortable you are with failure. You're going to start seeing that your team is going to have a lot less of those really long outages when you are in production. And as you see organizations start doing the work, you're just like, I'm cheering for them on the sidelines. Or when you hear about a really expensive outage, you're like; we can do better. We got this. And now you're just trying to herd like 500 engineers at a big org, like; I'm cheering for y'all. Like, #hugops, you got this.ADRIANA: It's so true. I think that goes with the mindset shift that Parveen was talking about earlier, where making it a safe space for people to feel. I think observability helps provide that safe space. But then I also think that it's up to leadership to allow for that safe space. Because I've been in organizations where I…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
