Tested by Covid with Greg Paskal

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 and today we'll be talking once again with Greg Pascal, all about Tested by Covid. If you don't know, Greg has been on the show more than any other guest, so he's official Test Guild main man Goomba, so you don't want to miss this episode. Greg is also a natural innovator, pioneering new approaches across quality insurance and test automation landscapes. Greg enjoys mentoring others to excel as a craftsperson of manual and automated testing. He's the author of Test Automation in the Real World, which you can get on Amazon and countless technical publications. He can also be heard on my podcast as always, and also he's the creator of mets, the Minimal Essential Testing strategy that some teams rave about. His approach is recognized in Taught by the ASTQB as an effective manual testing strategy. He also has spoken at numerous conferences including my Automation Guild as well as Star East, StarWest QA Trailblazers and a bunch of others. And he also founded the Open Test Technology Forum, encouraged collaboration and focusing on greater quality across the SDLC. Learn more about his work at metstesting.com real world test automation.com or recognize another dot com. I'll have all these links in the show notes so don't worry if you didn't catch all that. So great to have Greg back on the show. You don't want to miss this episode. I think it's going to be a unique topic. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Greg, welcome back to the show.

Hey Joe, it's so good to be back and see everybody today and get a chance to see you again.

Awesome. Great to have you back on the show and you pitched me this crazy idea for this episode so I don't know where we're going with this topic. But before we get into it, Greg, is there anything I missed in your bio that you want the Guild to know more about?

Well, probably the newest thing I'm working on right now is my new podcast@craftoftesting.com I've got a brand new YouTube channel, and I've got just done about seven or eight videos out there, so I'd love for folks to take a look and see what they think. It's just meant to be short little snippets of things that'll help them in their day job of being an automation and test engineer.

Very nice. Yeah. So a little bit about Craft of Testing is that Craft of Testing is the name of the podcast itself and it's a bite sized type of episodes around test, automation and testing. Did I hear that correctly?

That's exactly right. I just got a redirect. So if you go to craft of testing.com it'll take you right to my YouTube channel.

Excellent. Excellent. It looks like Greg has invested heavily in his studio. He's looking really good. So if you're watching the YouTube version of this, you can see him in action. All right, Greg, let's jump into it. What's the backstory here? What got you thinking about COVID and testing? And before we talk about COVID I want to mention neither Greg or I, we are not doctors, and we also any opinions that come up here are just our opinions, and they do not reflect the opinions or views of our employers, past, present, or future. All right, Greg, go ahead.

Yeah, good call, Joe. This is a crazy topic because so many people have opinions on it. Well, I am actually still at the tail end of my recovery of COVID About two and a half weeks ago, I was literally hours away from getting on an airplane to go speak at the QA Summit in Salt Lake City. It was a real honor to finally come together with folks and speak face to face, because we've all been, you know, doing most of this virtual for at least a year and a half. And wouldn't you know it, the night before, I could just tell something was up. And, oh, man, I wound up learning. A temp contacted the conference folks, and I said, I don't think I'm coming, guys. And the next morning, I wound up getting a test and bam, I had it. And it's been quite a ride to go through it. So, like a lot of things, you can take a moment like that and say, well, this really stinks. I sure wish I was in a different situation, but I think just my natural wiring is to say, well, you know, what can I kind of learn as I'm going through this? And before you knew it, I started thinking about, well, you know, here I do testing all day long. Whether I'm writing automated tests or I am, you know, coaching folks how to do that that well. And now I am on the other receiving end of being tested by Covid itself. And it opened up some just things for me to think about for these, you know, two weeks I was sitting there feeling just awful.

So what did you take away from the experience then, specifically after getting your results? I guess we should start with.

Yeah, well, you know, it's, it's funny because let's face it, who doesn't really have an opinion about, about this virus and what they're trying to do with it, including myself. I found that my natural wiring as a test engineer makes me curious and suspicious and want to ask question questions that look at data. I just, I think lots of test engineers can relate to that. We want to understand things. And I, I felt like, well, from the data I've got, this is kind of where I'm at. And so that led me to make my, you know, decisions that wound up where I was at. But I think this was my first kind of aha. And that is, I realized that because of the way we are wired as test engineers, it can actually sometimes blind us to look to subject matter experts for guidance. And so maybe in my case, my subject matter expert was my doctor. So I had a call with him just a few days later and he was able to enlighten me and help me understand some things and get a better understanding of just things I might have more concern about or less concern about or whatever. And that was probably when I started to connect the dot. You know what, I can learn some things as a test engineer through this experience, which is it's smart as a test engineer to look at who's around me who might know more or be more of an expert when I'm maybe working on an application and I think I've got all the answers there. And maybe I really need to reach out to the architect or the DBA or a DevOps team or something like that to say, hey, can I get a little more information about this so I can help make better assessments around risk than the things that we're testing. So isn't that funny how something can kind of lead down a road like this? It starts to get the wheels turning.

Absolutely. And I like the concept of going to a trusted resource that is an expert in their area. I see this all the time with performance testing. A lot of times people don't reach out to the database person, the network person, to try to understand the results in total. So you've seen that as well then? So you think testers in General probably could benefit from reaching out to other team members that may have expertise in a certain piece of the life cycle that they might not.

I think it's reasonable to say that, you know, we're experts at being curious and asking questions and hopefully communicating that information to the folks that matter. But it doesn't really make us an expert across the whole spectrum of technology. And it's just as valuable that you are a good communicator as you're a great question asker and a person that's able to seek expertise when you really need it. So there may be super DBAs out there that are also test engineers but, or, you know, super developer background folks that are also, you know, quality engineers. But there's a pretty good chance most of us aren't in that space of expertise. So it's important, I believe that we're, we're humble enough to be in a place we can put our pride down and say, I could really use the expertise of this person to help me make a decision. And so, you know, it's a bit of a stretcher connecting how, you know, going to a doctor for assistance might be how I go to a dba, but there actually is a lot of commonality around the same things that can come up. By the natural way I'm wired as a test engineer, which is say, oh, I got it, I've got it all, I figured it out. You know, I work with lots of test engineers, so I know how we can kind of naturally be wired sometimes. And yeah, we do our very best, but sometimes that pride can get in the way of us making the most informed decisions we can.

Absolutely. Maybe it's just me as a tester, I also go to the darkest place so I get worried about things. I find an edge case and think the worst case scenario is going to happen. And it freaks me out. I assume, like with COVID it's the same thing. It's like, oh gosh, this is a death sentence. I'm over a certain age and you know, it's all over for me. I don't know any thoughts around that.

That's a great, really good insight because I think I was in that place just about a week ago. After two weeks straight for me, I started to notice that every day my temperature was getting higher and higher. I had a fever for almost two weeks straight. And I would say towards the end of last week I was pretty fre freaked out that, you know, when's this going to stop? You know, I'm hitting 103 now. And it finally broke, thankfully. But, you know, again, it kind of helped me to think, okay, I've reached out to a subject matter expert, my doctor, and I reached out to him a second time just to kind of let him know where we were at. And he told me to stick with the plan. So think about it when we create a test plan, and yet, you know, the pressures turned up to get something done real quick. Well, going to my doctor and him giving me a plan which included certain vitamins and, you know, baby aspirin and Tylenol and a few of the things that he said, things I should stick with while I've got a fever and even after a fever to continue to keep, you know, my immune system strong, I continued to stick with his plan. And I'm happy I did because I feel a lot better today because of it and I'm sticking with the plan even though I, I feel, you know, 10 times better today than I did a week ago. There's something about having a plan when you're in a place of stress, you know, worry, concern, whatever it might be. We know when you get teams of folks come together and they're looking at a deadline or they know they've got a ship code to a, you know, a new mobile app or something, and week or two that can cause you kind of lose your mind for a moment and say, ah, we gotta just get this done. And that's the time more than anything that hopefully you've put a good plan into place and to follow. So that's my takeaway from it, is having a plan made a difference.

And nowadays with modern software development, do you notice that teams have a plan? I know back in the day I used to plan really well, but now it's usually like, oh, we'll figure it out in Sprint. Maybe it was just that, once again, I was in a dysfunctional team. But where do you see planning in today's environment? As a tester or in a software development Sprint team or using Agile?

Well, in your introduction, Joe, you made reference to the METS methodology. That's just one of many test planning approaches out there. The company I work for, we exclusively use Mets, which is minimal essential testing strategy. Metsting.com if people are interested in finding out more, the intent of that methodology is to be very lightweight. It's almost as lightweight as you could imagine to have test planning. It's all about prioritizing under this very short amount of time. These are the things that are most important. We test right now, but, but we continue to build out our MET strategy, our Mets test methodology, continually over time. So it's a dynamic kind of a living test plan approach. When we do it, then when we get really under, under the gun, we already have a plan to go to. That's why I like it. Yeah, I created it, but I've seen it. It's worked out really well. Like anything, you got to stick with it because the only thing almost left is just to wing it and to go completely ad hoc. So I think that there's a place for something like a Mets or some sort of where you've, you've provided prioritization to the test that you're going to run, and it's been very helpful. But that doesn't mean that we don't have moments where things slip and the next thing you know, you've gone full ad hoc. I have a thought around that, Joe, because I'm starting, as I'm doing more podcasts myself, to think about a reality that you and I have, I'm sure encountered, and that is good testing and bad testing look exactly the same from about, you know, six feet away. It's really hard to tell when you're just looking at someone, you know, typing at the keyboard, clicking a mouse, working on a mobile phone, whether they're actually doing good testing or not. So you put a lot of emphasis and a lot of trust in a test engineer that they have a conscious and enough integrity to truly bring good testing to the table. Because most folks that are not trained, and even those that are from a distance, it can look exactly the same. So can automation for that perspective. So I believe, again, if you don't have a plan, you're going to look busy and people are going to assume you're reducing as much risk as you could if you had a plan. And that's simply not the case.

Absolutely. And I guess having an automated test suite maybe feel like you have a mask on, even though a mask may not prevent you from getting Covid, I guess is another kind of point of view you can look at.

Interesting analogy. Certainly. We know lots of folks run to automating their entire regression suite. You and I have talked before on this. I have a different really opinion on that, that your automation complements the work with your manual test engineers. This is my personal conviction, it's a tool in the hands of a test engineer to give them greater insights of consistency of execution. Some of the things I refer to as learning about the personality of an application, your automation gives you great insight that this isn't normal. Just like the day, you know, the night before I was going to get on my flight, I'm like, look, I got my bags packed. I've got everything picked out for the morning for my early flight, and I don't feel normal right now. And that led me to take my temp, and lo and behold, hey, I had a fever. But if I had ignored that, I would have got on that flight or who knows what. And potentially it got other people sick or got stuck in Utah at the very least, you know, and not being able to leave, you know, teach at the conference. So the things that are automated tests give us insight, too. Just like you and I know the nature of our bodies or if we've got kids, anybody out there who knows, you know, one morning your kid comes up to you and they're just not themselves. And you wind up, you know, taking their temp and you're like, you're running a fever. Get back into bed and, you know, we're holding you back from school today. Our automation gives us very similar insights to things like that, that when you run it regularly, you're like, like, wow, this, you know, is so consistent. It runs the same way. And why did it run different today? Why did it run, you know, almost half as long as it did the day before? It's probably telling you, you gotta fail on the way.

So you got Covid, and I heard your wife and your daughter also got it. So was there any finger pointing? Like, sometimes you're on a team, like, you created the bug. No, you created the bug. I'm sure, you know, you have a healthy relationship. I'm not saying that was your situation, but could you find that that could also kind of replicate maybe certain team dynamics that you may have seen in the wild?

Yeah, actually, in our home, everything was great as soon as I got tested. The very next day, my wife got tested and found that she had it. And at that point, they said, you don't even need to bring your daughter and just count that she's got it. And so we all just started to get. We bought three different thermometers. We all had them, and all of us had fevers. And so we just kind of followed the same plan through it. But so I wouldn't say we were pointing fingers or anything like that. We just knew. All right, well, I guess we're gonna go through this, so at least be. Let's be supportive of one another. I found that it really did matter to have obviously not only family around, because we initially started isolated in the house and my daughter and wife were in another room. And that could be a lonely place. I can imagine for those folks that are single that go through something like this, how hard it is to be isolated from other people. I know people that have gone through it. They said that's the hardest part is being isolated. Imagine if you are on a team and you are given the responsibility of testing an application all on your own. How stressful that could also be. So just like it was nice when we could at least come together. Unfortunately in our case, because we were all sick with the same thing, it was really nice when we had friends reach out to offer, you know, maybe to bring some food over or if they could offer anything to help or even a phone call made a big difference. And isn't it funny that again, it takes Covid to make raise this thing up that we're made for community as people, even as test engineers, we're made to have others around us wanted to give us, you know, some people to bounce some things off of and just to relate to and hopefully sharpen one another in our craft of testing. So that was another takeaway from me is community made a difference in my recovery as I was sometimes freaked out about not feeling better, knowing that somebody knew I was home. My office folks, my boss, everybody were so supportive and I was really thankful for that.

I said, just thinking about when I started my career, we had a huge testing organization of just testers and it was an awesome community. And then when they started transitioning towards agile, they used to take testers and just put them on a sprint team and they were the lone tester and they felt more and more isolated. And so I guess this can kind of relate to that as well, that how do you, if a tester finds themselves in that situation or they feel kind of prideful, that, hey, I'm the tester on the team, I need to do it alone. Are there any actionable steps they can take to actually create that community? Maybe within the organizations that may be split up Sprint by Sprint?

That's a really good question. What I am seeing at least in our teams when we break up into smaller groups, is they do feel connected with their developers and UI folks and business folks, sometimes almost to a fault, believe it or not. They become such an advocate for the success of the product that they can take their tester or hat off for a moment and want to do whatever it takes to get the code over the finish line, which is good. But we often have to remind them, like, don't forget you're the, you're kind of the, you know, the final say on should this go or not or you're the one to, to identify when there's an issue. So weekly we do come together as a team, even though we're spread out like that so that we can sharpen one another. We're really fortunate in our new campus at Ramsey that we have a cafeteria. So we come together regularly for lunches, just kind of casually. It's not anything formal. I lead our automation team and once we set up a lunch once a month for everybody to go out, grab a bur and just spend some time together. And then we also meet as a team twice a week just for some stand up and kind of talk about what we're working on. And I usually have a little tip for them or something, you know, to kind of chew on for the week. So I would say this goes to common sense, but do what's necessary to have community with your fellow test engineers. If you're the only one there that's a test engineer, find, you know, a couple folks that are in tech with you that you know, you can feel some support from in the work that you do. You'll really, it will, it will help you out. And when you're feeling a little unsettled about, I'm not sure if I'm looking at a bug or, or whatever, you've got someone else to bounce it off of and kind of, you know, get a second thought on it. And by the way, don't forget about great opportunities, like even starting a meetup. Joe, I'm doing some of the most interesting meetups. All right now. I've got one I'm going to be doing next month in Rwanda. I've done one in Saudi Arabia a few months ago in Austria. I love the international ones, just some of my most favorites. But I got one in Austin coming up in a couple of months as well. So I love to help our community, encouraging them to come together like that. So even if they're one person within a company, they can at least as a community, come together in their city and talk about the things that they're doing around testing around automation, test planning, all those, you know, all the moving targets of the work that we do.

Absolutely. I was just thinking probably over the past year or so a lot of testers probably had to start working remotely, which I love. And I've only worked remotely for like 13, 14 years. I would never work in an office, but I'm sure there's certain Weirdos that actually like people and like working in an office. So they may felt isolated as well. So it sounds like they've probably gone through this already in a sense without actually having Covid still being self isolated on a team.

Yeah, yeah, Heard that people really loved it for a season. It's probably some folks are really wired to work remotely, but I again, my personal belief is we're made to be in community with people. So that may suffice for a season. But somehow or another you need to have a community of people in your life and it's awesome that you maybe have your spouse or your kids, but even outside of that just to have, you know, people you're mixing it up with and you know, the kind of common sense things we all know how it feels great to just spend some time with friends. And so it's also pretty awesome. I lead a meetup here in Franklin, Tennessee and people love to come together. We love to chat and just learn about what we're working on. Even if the topic that's being brought up has nothing to do with the specific area I work in, it's still great kind of seeing people's passion, what drives them to be a craftsman in the work that they do. I always find there's something I can glean with spending time with other technologists and people who have a passion for the things that they do.

Nice. And in the pre show you mentioned something about care versus service. You noticed that quality difference was noticeable between those two types of perceptions or type of services. So you just talk a little bit about what you meant by care versus simply a service.

Yeah, that's a really interesting thing that I found that as, you know, a week went on, we were starting to get low just basically on food in the house. And I actually don't use a lot of services for like Uber Eats and things like that. I had never used Uber Eats or Delivery Dudes. I had never used the delivery service for my supermarket and I needed to. We were simply were out of certain things that we needed. So was the very first time I'd ever done that with the supermarket. And I think about a again as someone who's a test engineer and a desire to test a product the way that the customer is going to use it. I found that I think it's called Instacart is the one that I use. I could have used any number of them, but I think that's the first one. I had someone in the market literally shopping for me. It was really neat that when they Couldn't find something, they were able to alert me. And I'm like, yeah, get that instead. You know, I need that watermelon luxurator. Those apples look fine. But when you choose a service like that, if you think about the way we test things, sometimes we test them in functional little areas and we're like, yep, new feature, done ship it. When it became an end to end process that I had to, you know, I needed to experience as an end customer, that's where I started to notice the defect. Not only once, but twice. So my first time, the very thing that inspired me to start my Instacart order was the very thing that got forgotten and not delivered to my house. And they there was no easy way to get back to the person shopping. And so I had to contact the folks through the app and they refunded that. And I'm like, well that's great, but I still need those things. You know, between all the other fees, it was maybe another ten dollars and I'm like, I'm going to spend another ten bucks just to try this out again. So I contacted a friend who went and got those items for me and just brought them. So it wound up probably being more effort, especially at a time I really could have used that service to work well. And I think there's some good takeaways for service providers to make sure you put yourself in the shoes of your customer and see, you know, what would it be like if this person was at home and this got done with surgery and they needed this service to work well? Do we provide an easy way for them to get back to the shopper? In this case they didn't. And so I kind of was frustrated with that. But I managed to get the things we needed. And lo and behold, would you not believe that about four days later I needed to use the same service again for some fruit and stuff. That that's primarily what we've been eating. And can you believe that the very thing I started the order with got forgotten again? I almost couldn't believe it. Two times around I'd only use the service twice. So I thought, oh, that's a good thing to know. And I've actually already shared that with our team is make sure for the, that we make that we put ourselves really in the end user's shoes and what would be like if they walked all the way through here and then they've even paid for it and it doesn't show up how that would make them feel as a customer? So that, that's was my experience using a service. And again, the people who made the software, I know they did their best but they're going to take a different interest. And I really was kind of seeing the fruit of the quality engineers who tested the process and I realized they had missed probably some very important steps in the process. When I contacted a friend to get that stuff for me, he on his motorcycle went over to the supermarket, picked that stuff up and we had it in the house and you know, 40 minutes. And he took a very different perspective as someone helping us and giving us a service, which was these are my friends, so I'm going to go and help them out. So what does that mean for testers? I would say, well, don't lose sight of the fact that you might be on the receiving end of a product that someone's testing. So test your product as if you were the recipient and really think about all the things that you would want as a, you know, as a product provider. That really feels like when I use the service service that this company really cares about serving, serving me well.

So besides quality of care and things like that, I think the last point you mentioned was do the work in the way the customer would expect. I guess that kind of goes back to what you mentioned earlier. But any more thoughts around that?

I just think we can never lose sight of this as quality engineers, as automation engineers. A little harder as an automation engineer because it's hard to automate something exactly as a person would because we're missing their intellect and their brain. But it doesn't mean we can't follow at least a similar series of steps that likely the customer is going to go through. But I always think about automation engineers are first got to be really great test engineers. Whenever I bring on a new automation engineer, I'm like, look, you need to be a rock star when it comes to being a test engineer. You need to be one of the best on the team because if you're not, you're going to just write code. What I call passing automation, but not testing automation. And you need that mindset of what I'm, I'm writing is testing something or verifying things along the way to give me good results, not just writing something that can pass. It's a problem in our, our, in our community to be really honest. And I think in some sense there's more tools than ever that are erring on the side of passing tests, not testing tests. I just heard of another one just the other week, a whole philosophy about writing self healing test. I don't agree with that. I don't agree. We err on the side of forcing a test to pass. I think that's a that leads us into trouble. We should always err on the side of if this test follows the requirements and the way I've written it, then I actually want it to fail. When it doesn't do what I when it encounters things I wasn't expecting, that gives me the insight. It doesn't blind me to it.

Okay, Greg, before we go and one piece of actual advice you can give to someone to help them with their testing efforts they could put into place right away. And what's the best way to find or contact you or learn more about your new efforts?

Sure, Joe. Well, if I can leave everybody with one tip to take away is don't lose sight of the fact that what you are testing, that there's a real human somewhere who's probably going to use the software and you need to be as thinking about testing that software as close as you can to the way they're going to use it. It's going to matter to them. It's going to speak well for your brand and your company that they care about their customers. Customer. So I'll leave that. That is my tip for the day. And you guys, I'm really easy to find online again. I'd love for you to come and visit the new podcast@craftoftesting.com and I'm very easy to find on LinkedIn. I love connecting with all of you on LinkedIn, so please just find me out there at Greg Pascal and I look forward to connecting with you soon.

Thanks again for your automation awesomeness. The links haven't done the value we covered in this episode. Hand on over to test guild.com forward/A361 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 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 awesome. And us as always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild. 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.