From Unemployment to Upskilling with Greg Paskal

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast. And today joining us once again we have Greg Pascal. It's his nighttime joining us, the reason why he's on the show. He's an expert. We love having him. He always brings a lot of insight and today we're going to talk about things like catching up what he's been up to with software testing and automation, some key takeaways he's gotten from attending or speaking at some testing conferences this year. And I think he spoke about the seven fundamentals of a successful test team, which we'll probably dive into as well. If you don't know or if you haven't been listening to the show for long. Greg is a natural innovator, pioneering new approaches across quality assurance and test automation landscapes and he's mentoring others across the board. He also excels at craftsmanships and manual and automated testing and he is the author of Test Automation in the Real World. But we'll have a link to all these in the show notes and he's had countless technical publications. Greg could be heard on previous Test Guild podcast and he's the creator of mets, the Minimal Essential Testing Strategy. We've covered this in previous episodes as well and he's also spoken at numerous conferences including the Automation Guild, Starry, StarWest, Pacific Northwest software Quality Conference, QA Trailblazers and a bunch more. And he also founded the Open Test Technology Forum where he encourages collaboration and focusing on greater quality across the software development lifecycle, which he's one of the experts and you can learn more about him and I'll have a link to this@craftoftesting.com and that'll have all the links as well for all his other websites and resources. Also, I think Greg may also be available for hiring joining a team. If you're looking for someone that's an expert in software testing, testing automation, looking for someone to drive any initiatives or anything like that, definitely check them out as well and I'll have a link there to contact them for more information also. But anyway, let's get to the show. You don't want to miss it, check it out.

This episode of the Test Guild Automation Podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to Your brand awareness, lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us, from boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild could take your brand to the next level. Head on over to test guild.info and let's talk.

Hey, Greg, welcome back to the Guild.

Hey, Joe, it's good to see you again. It's been a little bit. I love always getting to spend some time with you.

Awesome. Same here. We love having you. Like I said, I think you're the only one that's been on the show nine times now. This is the ninth time, which is crazy. So thank you for that and thank you for all you do for the community. Doing things like this over a long time span. It's. It's really a credit to all that you've been doing for everyone. So thank you.

Love to do it. Sure.

All right, Greg, so thought I'd start off by saying, what's going on? What's new? You know, you're usually doing different things. What's the current thing that you're focusing in on and how are things going for you?

Well, I'm really in between work right now. Finding the market is really tough out there right now. But, you know, I look at that as an opportunity. So I've been diving into IoT work. I've been learning C. I designed my first PC board and had that produced and man, I'm really loving it. I'm jumping into VS code a little bit, so learning how to use that. And one of the newest, coolest technologies is a GitHub copilot. Have you heard of this thing?

I have, yeah.

And oh my goodness, you know, I'm one of those people that I kind of need to see it firsthand. There's a hype out there always about this stuff and so I wanted to give it a first go around and I'm really impressed by it. So that's a lot of what I've been up to.

So Copilot AI, let's already get into it.

Yeah.

You've been around in the industry for a while, like I have, and you've seen things come and go and hype and non hype. And so you just mentioned GitHub Copilot. You needed to see it in action. So is that we feel across the board for AI, what are your thoughts on AI and where we're heading now with ChatGPT? And all this madness.

Well, I'm sure a lot of your listeners know who Jason Arbonne is. Jason and I are really good friends and man, I just got the incredible experience at the Pacific Northwest Quality Conference to spend about five hours with Jason, you know, one evening and we just sat and talked. And if any of you have ever sat with Jason, this guy, his, the way he thinks about things is incredible. And so I always love it. Whether I'm at the Star conference or whatever, we tend to meet up at a conference. And that's exactly what happened. And so to me, he's kind of the go to guy when it comes to AI work and testing. And so I had a lot of questions for him, I went to his seminar and we talked through it and I said, come on, help me, you know, understand. I'm trying to separate the hype from what's real. And so he gave me some good things to think about. And some of the aspects of AI neural networks are so complex, they're really hard to get your arms around. He admitted that he's like, we're not fully sure exactly how some of this actually still works, but when I came home, I decided, well, you know, I'm, I'm one of those people, I like this idea that a human is involved in the work of testing, right? None of us want to feel like, you know, our work is in jeopardy. And I do believe humans have a very important part to play in this. So I tend to be kind of like, ah, you know, AI, you know, stay away. But at the end, I also need to be objective enough to hear what's real there because there's a hype on this right now. And that's what led me to get into it. So like Jason, after I spent a little time, I wrote him and said, here's my initial takeaway after spending 10 hours with this tool. And maybe your viewers would be interested in finding this out, AI at least the pieces I've seen so far when it comes to something like Copilot is not for a novice to use. This is something a skilled developer or maybe an automation uses along with their existing skills. So it gives some good coaching. There's some things I had to tweak, not a whole lot, but enough where I recognized it doesn't understand the scope of what I'm trying to build. So it's trying to build me down the wrong path. And I had to make that course correction. I think that's important to know. Some folks might see this as kind of like this Magical, you know, wizard. You rub the, you know, the crystal ball here and, you know, code is going to come out. But that's not really going to be the case. I think still going to take people who have skill in their development, in their automation work and their testing work to evaluate is the advice I'm getting. Good. And how is it assisting me to go forward? Think about a carpenter, right? If we go to my garage right now, we're going to find I have about five different hammers. I've got a nice finishing hammer and I've got one that I use when I'm really, you know, doing kind of demo work or taking things apart and they both, you know, achieve success in what they do. AI, I think is going to be like that. You will use this tool to fulfill things that might be very helpful to you, but will it solve all your problems? Probably not. You're going to have to direct and guide it. But where you'll be amazed is where it's able to aggregate other information that it's found and provide it as a hint of what you might want to do next. That's the big win. I found it. I like it.

I totally agree. I use it all the time. More like you said, like an assistant or a sounding board or what someone has told me before, like a friend. Sometimes it gives good advice, sometimes it gives bad advice. It's up to you to say, okay, I don't know if I agree with that one or hey, I didn't think of that. It's not exactly what I'm thinking, but let me go down that rabbit hole with something else in my own thoughts. So it's almost like a collaborative kind of session or. Yeah, kind of with it.

It's a great way to put it.

Yeah. So what was your main concern with Jason? What Jason told me once that really caught my attention was, hey, if this is going to start generating code, what do you need to do? If you have more and more code, you need to test it. And so there's going to probably be a need for more testers. I don't know if, because he has a testing background that that's why he has that angle. Any thoughts on that?

I think from a testing perspective, or let's just jump back even further from an AI perspective. An AI perspective. My question to Jason is if this is consuming content, obviously it's not dreaming this up completely on its own. Not yet, at least. But if it's consuming content, and I think about sites like maybe Stack Overflow, honestly, not one of my most favorite sites because you're going to get all kinds of words of advice there that are going to be good, bad and ugly. But if it's using that as a baseline, is it presenting, you know, not such a great baseline for us to move forward in? So we talked through that a little bit and I think he agrees. There's this reality that we can't be, you know, oblivious going into it. Some people will do that and they will probably produce things that you wouldn't want to trust your credit card information to or your Social Security number to or anything that would be really critical data. And so I still believe that because obviously it's taking what I'm submitting and doing some sort of processing on that. It's probably using external networks and storing some of that information so it can grow its knowledge base. So that's kind of my takeaway right now. I know that. Have you ever heard of the Gartner, what do they call it? It's the Gartner hype curve, Joe.

Yeah. Yep.

Wow, this thing's fascinating. At the conference they talked about it a lot. So if I could explain it to your viewers, it's your classic N curve. And I mean this little curve appears really tight and then it's like Schlitter Bond. I mean, you know, it's really goes down and you're just on this roller coaster, right? Ah, well right now AI is right at this hype area right here. As a quality engineer, that's good to know because you need to be aware of what is hyped trend right now. And if you don't think AI is, you're naive. It's totally there guys. And so you have to understand that everybody thinks this is, you know, going to do a whole lot of things, but there's kind of a reality will eventually hit a what it actually can do. That's normal. All tech, when all technologies go through that self driving cars are kind of on this part of the curve right now over here. So if you don't know of the Gartner hype curve, it's really worth looking that up because I think you'll, it'll give you some good tools as a test engineer of where to be aware of tech, tech that is coming through.

Absolutely. I'll try to have a link for that as well. A great, great resource there also. And I see your, your concerns about what it's been trained on. I've been seeing some newer tools come out that uses like ChatGPT behind the scenes or other Technology, but it gives a citation where it found the information. So you can say, okay, show me where you got it. And there's a link so you can make sure it's not making things up or hallucinating, which is really helpful. But I say, oh, this is garbage, because it's citing. This source I know isn't too credible.

Yes, of course.

So now you spoke about, you were at the latest Pacific Northwest Software Quality conference in Portland. I believe you gave a talk on seven fundamentals of a successful test team. I don't know, we don't have time to get into all of them here, but any key ones you want to kind of point out before we dive into some other topics?

Well, I think fundamentals, the first one I talk about in that class is around the language. If we don't have a common language, we're speaking as a team, then we're going to have trouble. And I gave the example in the conference of the word bug and defect. Now, where I was just employed previously, those two words meant two different things, and I think that's trouble. Those terms for the majority of the quality community don't mean two different things. They mean the same thing. One's a slang for the other. So I'm in this position where I believe it's important to identify terms that the team uses. Now, in this case, they decided to kind of make up one of those terms meant separate from what it actually, you know, is taught in the ISTQB content, which I really love. And so that introduced a risk, ironically, because if we hire a new quality engineer to come in and they begin to use that term in the way most of the industry does, you now are not talking apples to apples anymore. So the first tip I usually talk through is a common language as a team. And so maybe you go over the basics like a good example, positive, negative, and boundary testing. These are fundamentals. All the test engineers I work with know well enough they could give it an elevator speech and they can teach it to anybody. It's almost a requirement. But how often do we hear about things like happy path testing? I referred to this in my class. I don't like that term because happy path only really leaves one other metaphor, which is sad path. And ironically, most defects aren't found at either of those ends, believe it or not. They're found in the middle. And that's why we have boundary testing approaches that are taught. So when's the last time you heard someone talk about melancholy testing, which would be the only way you could almost make the metaphor work. This is a case where language is introducing the potential of a risk, even that we introduce into the life cycle by the words that we use. So I got to spend some time with our development engineers and introduced that we use these terms. They really like the idea. They could see how important it was that we standardize on good terms and the metaphors matter. Right. Joe, you and I know we speak in these word pictures all the time so that we can help teach a concept. So ensure that as a teacher, you're using a metaphor that works well to teach the concept and doesn't limit it. So language matters. And that's one of the, you know, the first tips I talk about. I get into automation and some other things, how to pick good automation, how to build some beginning test plans and prioritization. But I've taught this class for quite a few years now. It's always well received and it was well received at the conference as well.

So this is what I like. You know, you told me what it was about, but how did people, what were some takeaways then? Did people come up to you after you said this, said, oh, wow, I didn't think of this, or this is something I'm going to implement when I get back. Anything that really resonated with them that maybe you weren't expecting or that you were more than one person maybe highlighted?

Yeah, a real common one came up here as well is what to automate. I talked about the idea of not putting numbers to automation. You know, how often have you heard we're going to automate 80% or whatever. I think that's not a good approach to go forward in. You should automate the things that are the right things to automate. If that's 80 or 90% or 20%, that's the right answer. Okay. It's not a numbers game when it comes to automation. So we talked about in our test planning and I introduced the METS concept, the minimal essential test strategy. We've talked about that on your show before. And for folks that are interested, you can go to metsting.com and I've got a whole site on there on that. That is a test planning process leads you to build prioritization in the, in your test. So you identify a number of categories based on the functionality of an application. And then what would be the critical, high, medium, low, things that you would test. And so the way I coach folks when it comes to automating is consider your critical tests that you've identified first as your automation candidates. And you Might even find some there that still aren't a good candidate. But start there and move to your critical and highs and you may find that your mediums and lows, the. They're just not that critical enough to automate because you have to maintain whatever you build, right. That for whatever reason, giving that strategy to test engineers, it seems like they have a sigh of relief. At least they've got a plan now and a strategy, and it's not, well, I'll automate 80% of everything. For those quality managers out there that are using those numbers, I'd really want to encourage you step back from that. That's kind of a madness that you would just go ahead and pick a number to do when it may not be the right thing to do. And now you've added overhead and maintenance. Anything you automate, you'll need to maintain going forward. So, you know, put that towards something more worthwhile or maybe you automate more than that because it makes good sense. So that was one that definitely came back. And it's come back many times, Joe, that people find is kind of an eye opening.

Greg, this might sound weird, but do you see being competent as a disadvantage working it in certain. I don't why this came to my mind. You have so much breadth and depth and that when you go against what people are saying they should be doing when it's wrong and you say that's wrong, it almost seems like people, like, with your experience, almost seem like a liability rather than like, we should listen to this guy. He knows what he's talking about. Rather than just following orders and saying, oh, I automated 10,000 tests today. And they're like, oh, look at this guy. You automated 10,000 tests? Like stupid stuff that I don't know. Does that make any sense? Is it just a cultural thing depending on where you're from or where you're working?

I think it's a good point. I heard a great talk on empathy at this conference, believe it or not. What an interesting thing to come up at a testing conference. Andrea Goulet. I don't know if you've ever had her on your show, Joe. She would be incredible to have.

No, cool. Good to know.

I did a talk on empathy and kind of in a technology organization, how you do that. And from a quality perspective. I thought it was interesting to hear a soft topic. But, you know, her takeaway was if you think about the developers that have written the code, what's one of the most powerful things a test engineer has if it goes to their head is they have the ability to call somebody's baby ugly. Right? Their code, the thing they poured their guts into. Anybody who's had any sort of, you know, artistic endeavor, whether it be writing code or painting or whatever that might be, knows what it's like to know, pour yourself into something, and to have somebody come by and say, you know, this sucks because of this is really insensitive. And Andrew brought up a really good point. We have no idea what time frame that person was given, if they had been given any training at all. And so I like this idea of empathy in the workplace and that we speak about it because it matters. When I teach the ISTQB class, I. I often take my test engineers through this exercise where I have them draw pictures, and I say, you can draw a flower, a car, a home in a house, a couple of things, and I have them paste them all up on the wall. So we've got 20 or 30 of these things up there. And then I say, okay, I want you to pay extra special attention to how you're about to feel. And I start to go through, and I'm like, look at this flower. These petals are clearly not the same size. And what flower do, you know only has four petals? This is dumb. And then I look at the car, you know, and I. I intentionally go in and try to do some things that are, you know, ridiculous, but I want them to internalize what that feels like. It's important. This is the empathetic aspect I think Andrea talked about, which is, remember, you're still dealing with a real person there that developed that code. And the best thing you can do to reduce risk is to build a relationship there that's better than any test case you're going to run, is build communication and trust there. So when you've got to share something hard, you can come in and say, hey, I found this thing. Can we walk through this? I'm not sure if it's a defect or not. And maybe it's not that big of a deal for him to fix or her to fix, and you can go forward. It's these sort of skills that I think really separate those that do this as a craft and those that are just kind of getting the job done. And so I think there's a lot of opportunity to grow there. But you're right, the work we do can be, in a way, threatening. Can you believe, Joe, I've been working in testing and automation 40 years now. This was the official. I almost can't believe it myself, because, you know, I Figure I'm going to get on my skateboard or my any moment, go do some things. But things have progressed. But it can be threatening when you come with some of these suggestions, because many quality engineers are given directives like, well, we're going to automate 80% of the things or whatever. I think that sounds really good. Maybe in a board meeting or somewhere where you have to have metrics. Remember, as the representative of the quality organization, this role takes enormous courage and integrity to do well.

It really does.

I've been writing about this to our community almost weekly on LinkedIn. The things we have to say are hard are sometimes very hard things to share with folks, and they can also be very celebrative as well, and something we can stand up on. But as soon as we compromise our integrity for the sake of getting numbers done, we began to walk away from the very thing we were hired to do. This is not an easy work. All right, It's a hard work, but I like it because it means I need to come with my best, the best skills I've got, and communicate kind of in a caring way. But what I have discovered as a risk so that we can address it. And then they could decide whether they want to ship the code or not, that's okay, or fix it, but I need a place I could do that. And.

Well, great advice. Absolutely. So, Greg, you know you mentioned another topic about IoT.

Yes.

I've been hearing about IoT for years and years and years, and I always say, oh, it's going to take off. I guess the hype curve. I don't know where it is, if it's going or not. But where are we with iot? Is it a skill automation engineer should still be concerned about or think about or anything special about it that you think people should know about?

Yeah. One of the speakers can't remember his last name. His first name was Costa. He did one of our talks at the conference and he said this is a skill set that's hard to come by in our field. Now, that's good for those of you listening, because what that means is we've identified a field that doesn't have a lot of. A lot of expertise in it, and it makes sense iot. You're working with embedded systems, you're working with systems with no screens. You're having. You almost need the skills of a good troubleshooter and a developer in order to work in IoT. I found that my testing skills and my development and even my electronic skills, most folks don't know, I have an electrical engineering background as well. All come into play in this space because you're dealing with literally IO input and outputs, sometimes at a chip level, just coming out as a signal that's plus or minus 5 volts or 3 volts in some case. I found, talking with Costa, that I was already moving towards where some of the gaps are just naturally. But it helped me to have a background in it. And that is since I'm dealing with, with chips and boards and things like that. Like, here's my kind of my latest, you know, board I'm working. This is my board prototype. And so this board is made up of a microcontroller and some LEDs and resistors and some other components. To test them, I actually needed to write some software to actually test the IO. And all it does is it outputs to a terminal whether certain things are happening the way they're supposed to. You can see how different that is than us surfing, you know, with Chrome or something and, you know, checking that our data persisted here. We're wanting to see it persist within a small chip or that sort of thing. So I like the field. It's very technical and I'm such a nerd for that. I enjoy it. But for those of you that like that kind of thing, there's great opportunity here. And I'm exploring that right now as I'm kind of in the market looking for work. Is maybe this is a time for me to make that transition more into firmware testing as well, because I have that background. So, Yeah, I think IoT space, Internet of Things is very interesting. It's everywhere, it's all around us, and it's incredible to work with. I learned about a technology, I got to tell you, called Lora L O R A. It just blew me away. The circuits that I'm working on here use WI fi. And have you ever considered that WI fi, for the most part, is meant to contain within your house? It's meant to be kind of a short distance of transmitting high speed data. Well, Lora is a technology that can transmit data over a mile or multiple miles, in some cases hundreds of miles over through some very small chips. But it uses a different way to communicate that information, and that's brand new to me. Here's a technology this long and it took that long to find it. I built one, I couldn't believe it. I drove about a mile from my house and this little chip sitting on my desk was communicating with me a mile away in my car. And so these are sort of Some of the technologies that are available for those that might be interested in getting into the IOT space. It's fascinating.

That is awesome. I bought some property, so we built like a little mini farm and I can never get a camera to go WI fi camera to go as far as I want to the gate, because I have to walk really far to get to a gate to open it up for people. I should look at something that has that capability, because that sounds like it would help.

Absolutely.

So what language did you use to create that program to test that board that you talked about? C. C, right, yeah. So what language do you think I know C or C, probably be skill. Is Python use it all for IoT as well?

Yes, it is. So in the IoT space, Python's really a very popular language. I mean, list, Python's a great language. It's a markup language. I find working in C debugging this code is really hard. Some of the hardest debugging I've ever personally done. I literally have to hook up another circuit board through a serial connection and I have to peek inside the physical memory locations of this to determine what's happening. It's easily one of the hardest debuggings, like I said, I've ever done. But when you look at a markup language like Python or Ruby, which is what I've been using for the last eight years or so, you get spoiled in what it means to put breakpoints in places and watch code execute its way through. When you're working in something that's an embedded system that gets compiled and pushed inside, it can be a lot harder. So. Absolutely, I think Python's a great way to go. I got started with some of this stuff, like a lot of folks with Raspberry PI. And then the Arduino ide, which is just a development environment for microcontroller systems, led me down this road. And now I'm working with a great chipset called the ESP32. And, man, I love it, it's so cool. And so I'm experimenting with it more and more and blending that with GitHub, a copilot, has been very fascinating. So, yeah, it's kind of a new. A new hobby and it's something I really love to work on.

Ok. I also love. You're always positive. So, you know, there's a lot of people that find themselves in a situation now where they've been unemployed for a while. A lot of, like, I think LinkedIn just laid off 700 employees. I don't know if anyone ever viewed Unity before, but they laid off like half their staff. Yeah, a lot of layoffs going on. I know. So I'm just curious to know from your experience, what could someone do to stay positive or stay like, not get discouraged, you know, I was laid off years ago. I haven't gotten a job since. But like, how do you keep it up? Because I've never heard you like down in the dumps. You always keep moving forward, always learning. So any encouragement you give to anyone.

Else, well, I'd be faking it if I told you I don't feel down. From time to time, I do. I've allowed that to kind of help me of focus into our community where I can make a difference. I'm very intentional with how I slice up the day and I've applied it over 75 companies now and the job market's very different right now than it's ever been in my career. So you have a lot of folks that you'll never hear a peep back from. I've had a number of interviews where it sounded like they were going to go forward and then just crickets. Those things can really put a damper on your spirit for sure and make you wonder, am I, do I have anything to offer anymore that's valuable? That's just not the case. So the way I've tried to approach it, Joe, is I consider, well, I've got this season to improve my skills, so I'm going to go ahead and really press in. I love what I've learned in C. It's a language. Some people are like, oh my gosh, you did that? And I like it. I enjoy the stretch. And you know, I've been writing a lot, a lot. I wrote a new paper. It took me six months to write this paper called 360 Degrees of Risk. It's now published on LinkedIn and on my blog, realworldtestautomation.com that came from this time of really saying, hey, how can I bump up my game here and step back from what I've been observing over so many years of testing and where are in that case? That paper is all about risk in areas that we often don't consider at all. So I think it's great hanging out with the community. I've had some incredible conversations with folks, good friends like Randy Rice and Jason and a number of people I've, I've known on LinkedIn for a while have reached out just to check in Chris Tremper and some of our good friends like that you and I know, both, know him well, have really been a godsend to me and have just checked in. So I'd say find your community and, you know, let them know what's going on so they could be an advocate. But you might be surprised. They may just check in every once in a while and see how you're doing. Because it is a strange time out there in the market right now. There's a lot of fear that AI is taking our roles away again. I don't think that's the case. I don't see that. But as with anything, when it's your family and you've got to feed them, those things can come knocking, you know, for me, more late at night, and I worry about it. And then I'm like, all right, things are going to be okay. Just keep moving forward. Try to pour in to our community and do the best you can. That's how I've tried to handle this. Just pour into this group of people. We care about them a lot, and we care about the field we work in.

Drives me nuts, because it's a lot of people like you at a high level with all this expertise, and they're still looking for jobs. And it's making me lose my trust in the industry or my faith. So if you're listening, make sure you hire Greg and let me know you heard about him here. Cause it's driving me nuts. It really bothers me that, you know, people like you are still looking for a gig. I don't get it, but, you know.

Yeah, appreciate that, Joe.

Is what it is, Greg. So, any other insights then, from the conference before we wrap things up? My last killer question.

Yeah, I know. I don't want to forget this. I actually was just on a call a couple hours ago with a great. A great group, the Murano Group. They work with some ladies in Rwanda, Africa, and. And they're using them to do testing. And they've been taking these folks that really need a career and a craft and equipping them how to do it well and bringing clients to them to do testing. I love that. And I was sharing it with the CEO of that company just a couple hours ago, how much I enjoyed the work that they did. And he was asking me about conferences, and I said, what stood out about this conference, Pacific Northwest Conference, was that it's all volunteer, and so nobody's really getting paid the big bucks. They're all volunteering to do it. This conference, I got to hand it to them. They wound up paying their speakers. They covered the cost of my hotel, they covered my travel. Those are hard things to come by. As someone who speaks at conferences often, I had to cover that cost out of my pocket, out of Greg's pocket. And so having a group do that was great. But I think because there were so many volunteers, we found that everybody was pretty willing to jump in and help one another share what they had learned. And so all the speakers that got up, you got a sense that this is something they really did every day and they were just sharing the parts they had. Even though they may not have, you know, all of the picture figured out, this is the piece they did have. I like that a lot. I think as a community, there's no school of quality engineering like we learned this by podcasts like the one we're doing here, Joe, through Test Guild. And and so why not be a community that relies on sharing with one another? Let that be something unique about this field. It's a great field to make a living doing. So that stood out from this conference and I'm excited about going again because I love the spirit of the folks that I met that were very willing to give, like Jason and Andrea and so many of the others, Costa and so many of the others that I met. Some of them have been on your show. Some fantastic people.

Yeah, great event. They've been doing it forever. Pacific Northwest Software Quality Conference, if you're in Portland. I don't know if they have it in Portland area, but you definitely check them out. I actually ran the when Covid hit that, they did one online that I ran for them. Tariq contacted me. So great organization. Definitely a great tip for sure. Okay, Greg, before we go, is there one piece of actual advice you can give to someone to help them once again with their automation testing or any other software testing efforts? And what's the best way to find contact you or hire you? Greg, how can we get you employed asap?

Yeah, we'll bring that. Well, I always tell folks I'm really easy to find on the web. Just Google Greg Pascal G R E G P A S K A L and you will be surprised all the things that come up. So you can find me through gregpaskal.com very easily or LinkedIn. That's how you get ahold of me. And I'm really looking for a great world class company, really wants someone that cares about their, their test engineers and really building out a world class automation effort. But man, I'm kind of the whole package. I love all that space and I like to speak into it, you know, my advice is as a community, you know, challenge yourself to grow. Each Monday I've been writing, probably the last two or three weeks, I've been writing out to our community on LinkedIn, by the way, for not connected, please find me. I love to connect with, with all of you on LinkedIn. I've been challenging our community to try to bump a little bit each week so, you know, assess your skills and assess one small thing you can apply an hour to this week that can make you a better tester, a better automator by the end of the week and keep looking for those opportunities to grow. We need to kind of have the heart of a learner and that's, that's an important skill that you need to mature in. If you're not doing that, you know, be intentional about your growth. You will find eventually you'll probably get a chance to pour into others and mentor to them. I really enjoy the opportunity to mentor young engineers when you get that chance, when someone says, hey, I'm willing to mentor you, you gotta own it. You've got to own that. This is another part of my talk I had earlier with my friend Dan, is you can, you know, it's kind of like you can't. You can lead a horse to water, but you can't make them drink. And when it comes to quality engineering, if you really want to grow, find someone who can help you. I mentor people online, but I always require them to own it and set it up because I want to see their intentionality that, you know, we're being, we're putting the efforts where they make a lot of sense and where that time is well spent. So if you're given that, like, run with it, go with it, because it can be valuable to your family down the road in the areas of finances and a great career growth. And that's probably what I would tell you. Stay humble and try not to let everything go to your head and just pursue it in a way that you are a sponge to grow and willing to give to others. You will not go wrong with that.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode, head on over to testguild.com a475. 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 awesomeness. As always, test everything and keep the good. Cheers.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.