Timeless Technique for Test Automation with Marcus Thomas

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 here for a special treat today we have someone that is a automation expert that's been around for a while and he also has an awesome solution that's going to help you with a lot of automation problems. I'm going to touch on in this episode if you don't know, we'll be talking with Marcus Thomas all about automation in general. So you don't want to miss this episode if you don't know. Marcus is the president of Core Consulting Services and founded Core in 2005 with the foresight of understanding how automation will impact every sector in this economy. And you probably see it everywhere. Software rules the world and obviously if we have all the software, you need to test it. So Marcus is there at the forefront creating a test automation framework. In the early 90s, it's evolved into an enterprise online solution that both governments and private sectors depend on. So as I mentioned, he has experience with testing but so he really knows like what the challenges are. So I'm really excited to dive into today's episode. You don't want to miss this. 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 test guild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Marcus, welcome to the Guild.

How's it going? Joe, nice seeing you. Nice talking to you again.

Awesome. Good to see you again. We spoke earlier in the year about automation. I thought it'd be really great to have you on the show because you have a lot of experience in this area. Before we get into it though, Marcus, anything in your bio that I missed that you think the Guild should know more about?

No, I think you nailed it. You pretty much covered it.

Awesome. So in the pre show we mentioned that we both started using windrunner and windrunner was kind of the forefront of automation back in the 90s, early 2000s. So I think I learned a lot from Windrunner. One of it was that it had a certain programming language that made it kind of easier to create automation frameworks. So I'm trying to think of some of the issues we see nowadays with automation. People struggling with it and one of them, I think is lack of developer skills. So I'm just curious to know if that's something you see as well.

Yeah, absolutely. You know, so Windrunner, you know, it started the whole revolution of, you know, being able to automate tests. And I was, you know, thrilled to be part of that, you know, that whole legacy that we call it now. Right. So, yeah, some of the problems I'm seeing right now in this era of test automation is the mindset, the shift in mindset where we have managers and people that's in charge, they're looking to try to test faster. So they're hiring a bunch of developers to also do the testing. Right. So we're kind of going back to the pre Y2K days where we had test developers actually writing the code and also testing the code. And then all of a sudden we had this big issue and it kind of put more emphasis back on quality assurance and testers being in control, you know, actually validating the system is working correctly. So we fast forward now we're in agile development and you know, we're, we're now shifting left and we've kind of mastered that. And because of that we're making decisions now that we need to develop, you know, test cases faster, automate them faster, and we're hiring two development teams. So what EFAS does, it allows, you know, the ownership and the maintenance and the development of test automation and putting it back into, the hands of, you know, the testers and putting it back into the tester's mindset. So that's what I see happening and that's what we're trying to solve.

Awesome. Yeah, we're going to dive a little more into EFAS in a second. But before we do, it's interesting when you mentioned about development, so everyone thought it would be better. Oh, developers know how to develop code and so they'll write better automation. But you and I both know we start off probably as testers. So we have tester skills that little different than developers. So when you have developers writing tests, they're not necessarily looking out for maybe edge cases that it someone that has been in the testing background for a while will find. Do you find that as an issue as well, that you may have developers and maybe they'll do automation, but even if they do, if they do, their testing may not be up to par?

Yeah, exactly. Yeah, I see it a lot of times on the projects that I'm supporting where, you know, as you said, a tester developer is more tunnel vision. They're programmed that way, they're trained that way. And where testers have to look at, you know, they have to put multiple hats on. They have to look at the system from the developer's perspective, the user's perspective, and even a tester's perspective. And what happens, I see a lot is when a developer is developing the automation framework, they're developed in a very restrictive way where they're like, hey, they're only going to need to execute these scenarios. So we just want to make sure we cover these scenarios. You know, once the testers start executing those tests, they're like, hold up, wait a minute, we can't execute this edge case, you know, we can't execute this test with boundary conditions, you know, so that's where the lack of, of expertise come in when you have the wrong people in charge of the test. Automation.

Absolutely. I think you also mentioned that you almost have two development teams now. Developers that create the application, developers that create the framework. And I'm not. Maybe it's just my experience, I've noticed that people that create the framework are neither good testers and neither good developers. So, like, they have the worst of both qualities. Even though they're trying to mash. It's like they're trying to mash two together that don't necessarily fit. I don't know, am I being down? Like, you've consulted a lot of companies, I'm sure. Do you see that as well?

Yes, I definitely do see it as well. And you know, it's a really good point that you made there, you know, so what I noticed is that to your point where you have, when you're trying to match these two, like we. The new term, right. That we kind of came up with in the industry was, you know, ask that, right? Software development engineers. Right. And you really don't truly have that. You're either going to have a tester that's more lean into a test or you're going to have a tester that's more lean into the development background, you know, and that's been a problem where, you know, where people are assigned work to do to be able to automate their tests, they're going to have that leaning, you know, towards one way or the other. And depending on the way, the direction that they're leaning in is going to impact how they go about automating that test. And the other problem is, you know, is on the tester side, right. The testers do need to have some automation skills. They do need to understand how to write and write a script that's going to be reusable, that's going to be used across, you know, be able to be sustainable across multiple releases. So I see a problem in both ways, you know, but more so with the industry trending in hiring more developers to do testing.

Absolutely. So, you know, once again, in the pre show, we have a bunch of issues that we've seen in the field. One of them also was, now I'm not picking on Selenium. It's a lack of Selenium knowledge. So what I've seen is that a lot of times a tester is drawn to Selenium, but they need development skills in order to write nice Selenium scripts. But it's hard to find someone that there's a tester that knows how to write Selenium scripts. And I have the opposite experience where I have a team of developers, I show them, hey, Selenium, you can use it as a language binding that you are reprogramming in, shouldn't be an issue. And they just struggle for some reason running automation scripts with Selenium. So what are your thoughts on Selenium? Is there a lack of knowledge you see around Selenium or any downfalls you see using that approach?

Yeah, yeah. So Selenium, you know, oddly enough, I'll be the first to admit I stayed away from Selenium as long as I could. You, I was a big fan of uft. There was a, you know, obviously moving from windrunner and you know, the company that took over windrunner, they end up developing uft. Quick Test Pro was what it was originally. Well, actually, it was actually Astra Quick Test.

Oh, yeah, right, right, right. That's funny. Yeah.

Then they changed the name to Quick Test Pro and then it was U of T. And the beautiful thing that I liked about U of T, the object identification is like by far the best out there. And that kind of ease the concern of finding the right locators, right. Finding the right attributes that, you know, you're going to use to identify and interact with the application. That is the thing that testers and developers struggle with the most. That is the biggest, you know, cost in maintenance is handling those locators. And Selenium lacks that totally. Right. That's the biggest thing that I have against Selenium. But obviously there are a lot of pluses with it too.

Absolutely. Now, a lot of frameworks actually use Selenium under the COVID so they just. Selenium is just an API. Right. So you need to know development skills. But there's obviously software out there that uses it under the covers for sure. I guess another issue, even if you do kind of, know, programming Selenium, is how do you even approach test automation? Because Selenium, you could do anything, right? So I see that as a lack in skill and not just developers, but also testers. What are your thoughts on approaching test automation or maybe people not knowing enough about how to do that?

Yeah, I see that a lot. The second biggest, you know, problem that I see in the industry is now that you kind of understand how to find your locators. Okay, what do I do now with these things? Right? So, you know, I know that one of the popular frameworks out there is page object model. A lot of people use that, you know, to kind of get started with it. And that requires very heavy development, you know, a lot of understanding of how to build out the Java class, if you're writing it in Java, you know, building out the classes and building out the methods and understanding how you can use the various different libraries. But the approach is really the most important, right? You can build automated test scripts, you can even use record and playback. But if you don't have an actual approach for how you attract, I mean, how do you attack a testing and building an automation and testing an application, you're going to have major problems with, you know, maintaining it and sustaining it. So overall, you know, my take on automation is first, identify exactly how you want to build a test automation framework that is sustainable, you know, and it's.

Easier said than done, for sure.

That's why I assume you probably came up with your own solution around this. So you're having me really Ms. Winrunner. I sound like an old guy, but I really loved winrunner.

So anyway, me too, man, me too.

So you brought up another point that made me think, you know, what I think a lot of people struggle with is, you know, with Maybe not just WinRunner, but back in the day you had these solutions that integrated seamlessly with their in an ecosystem. So you had winrunner talk to test director and you were able to, you know, know what the automation tests were validating and map things to requirements. And you kind of could do that now with open source, but it's kind of like a Frankenstein type of solution. So do you see lack of knowing what automation tests are validating when someone's creating an automated test, are they just doing like a endless user journey or like what are some downfalls you see people struggling with now trying to create an automated test?

Yeah, I definitely see that. Problem there because we're moving in the direction where most of your automation is either record and playback and that means you're writing and reading scripted language or you're writing these classes. That should mimic what a test case is, but it's also written in code. No one but the author of that test case understand the test. So you're now trusting when that test runs in the regression suite and it passed or if it fails, you're trusting that the person who authored that test actually did add all the checkpoints that is supposed to be added there. You have screenshots that you can probably capture. But is it actually completing and executing the actual test steps that the test case was intended to do? So I see problems with. I worked on a project actually, and they had a build out an entire framework using the page object model and they had like 80 test cases that were written. And I asked the tester, okay, can you tell me what this test case is doing? And even when he was going through the code, he couldn't explain to me what the test was doing. Right. So that's a big problem as well.

Oh my gosh, just thinking of this, I worked on a team, like eight Sprint teams that did automation. They didn't understand. I don't know why, maybe it's just a bad practice, obviously. But obviously they couldn't understand what each test was doing. So they'd always write an extra test that was duplicates or what they would do is they, they make a modification to a function that did the same thing. But they didn't want to break anyone else's code, so they'd create this. It's just madness. So I just see that as well. And I guess that gets into maintaining automation scripts, right? Cause when you have this code base, a lot of times you have all. It's hard to know if you have duplication, it's hard to know if people are not using page objects correctly. So how do you approach maintaining an automation regression test suite then?

Yeah, so we use fast. FAST is using. It's an open source framework that we put out there. And it's the old classic keyword driven framework. Right. You know, I haven't seen an approach yet that beat that framework. I've tried them all. And the reason why keyword frameworks work is because you have two layers of extraction, right? You have your layer of extraction at the object level and then you have your layer of extraction at the test case level. And my experience is when you can build out a really thorough keyword driven framework that maps down to the object in the application. A text box behaves the same in Google and as it does in Yahoo. So your lines of code that you need to maintain is very minimal. Right. You can, you're going to just maintain your actions and your objects, you know, libraries. Right. So once you have that keyword driven framework, you know, set up now you're just going to associate those keywords with test steps that you want to execute in the test case. So that's kind of what FAST is built on. We added a few more capabilities that we also think will be helpful. Data generation is a very another key component. Right. You can build all the automated test scripts, but if you start to hard code data that you need to enter into the application, that causes maintenance nightmares because you're going to be copying test scripts and trying to add data and then you're going to have to go to, you know, link it up to your Excel spreadsheets to get external data. So we added ability to also auto generate data at the object level as well. So that's one of the key things that we do with the keyword driven framework.

Nice. I guess sometimes, a lot of times I think when people struggle with in technology, they hear keyword driven, they're like, oh my gosh, it's from the 90s. I have this book on automation, got the name of it. It's my favorite book, but it's all about keyword driven automation and it's great. So they put it down like, ha, ha ha, we'll just use AI, machine learning or some sort of magic fairy to do it. So what do you say to folks that may give up that objection like, oh, we can't use keywords driven. That's like a, an old approach that doesn't work.

Yeah, you know what, I had that scenario happen to me, Joe. Actually I worked on a project, I won't name the project, but I worked on a project and they came in with this framework. I won't name the framework because I don't want to put any other tools down. But they came in with this other framework and it was like, yes, you're using keywords less like old and antiquated. Right. And implemented this framework and it took them about a year with full time developers. I would say about three or four full time developers. It took them a year to implement what I did with a smaller team that were not full time programmers by the way. In about three months. Right. It took me three months to build out a regression suite of about a thousand test cases. About three months. And it took them a year to do the same exact thing in this different framework. They required all of this code. But here was the funny thing about that, Joe. So when I joined their team to kind of look and see what exactly it is that they were implementing using this framework, and I was like, holy cow. You know, all of those things you talked about, right? You have these duplicate methods that are doing the same thing. You know, you have these libraries that are so written in spaghetti like language and everything, right? And so what I ended up doing was I created my universe and I actually called it Universal step, right? I created my own little universe within their framework that actually, you know, use keyword driven framework, but I use it in a way where they can build out their test script just by calling out keywords, you know, and it saved them time. And the testers that were assigned on that project, guess what? They couldn't do anything in that old framework because they couldn't write no code. Right? They can write the keyword that the framework came with, but they couldn't write the code that was behind it. So when I implemented my FAST framework within their framework, they were able to start automating their test cases right away. My libraries were much, much smaller than the libraries that they had maintained. It pretty much eliminated about 70% of the code that they wrote. So what I say to that is, you know, if you really design out a keyword driven framework, it's going to save you a lot of time, a lot of, you know, resources and a lot of headache even for the most experienced developers.

Absolutely. I guess a modern name for keyword driven nowadays is cucumber, and you have a lot of cucumber haters as well. So how did you develop fast or efast maybe to get around some things that maybe cucumber may be inefficient for. Do you believe in cucumbers like keyword driven? The same. And how does fast nefast maybe handle that? Objection. Then like cucumber doesn't work either.

Yeah. So cucumber it is a very high level keyword driven framework, right. Where to give you a different way of doing keyword, right? You know, you're using a gherkin and that's your keyword and that's kind of the framework that I'm kind of referring to. You know, you develop that initial gherkin language, you know, given the users on this or, you know, and this, and what would you have to do is you have to develop those function libraries behind it, right? And that's where the manual testers or, you know, people without programming skills struggle the most initially thought, oh, we can just do this, we can just write this feature here and write the scenario and then run it. No, you gotta actually build out the code behind it. You gotta build out the step definitions behind it. So what we did was we actually implemented the keywords where we would say, click, you know, the user clicks this action on this page, right? And now what that does, that one step definition allowed them to pretty much operate and interact with any object on any application. So it was taking the old approach of using the keyword driven framework and building that within the universe of the cucumber, you know, framework.

Wow, we're on the same page. I did something similar in my company. So I had something called, you know, the cucumber, which is feature file called a business layer. And the business layer was just like, like a keyword. And then that keyword would call a technical layer and that's where the code would live. So same exact approach for sure. So I guess, you know, windrunner was great, but I think one of the downsides was being able to run your tests anytime and anywhere. You could like kind of schedule it with test director, but then you had to have little agents on all these machines. How does something like FAST or efast handle being able to run in all the places, anytime, anywhere?

Yeah, so what we actually done is we have a few ways that you can actually run your test automation in efast and fast. We're a big component and big fan of open source code. So we allow you to go out there and download our runner, our Open fast runner, and use our Open fast framework and you can go out there and create a project. So the first way is just basically going out and downloading the Open Fast jar runner. It's a jar and it's basically a jar of our actual fast engine framework. So that's the quickest way to get started. If you wanted to start building out some automated tests. You download our jar to your local machine or to a vm, you go to EFAS and you start creating your scripts using our keywords, using our actions, and then you run that script using the Open fast jar. That open fast jar resides on your machine. And then you double click the batch script and it would actually run any test script that you build from EFAs. So that's the first way. The second way is we actually developed a runner. We call it the fast runner. And this runner communicates back to the EFAs. It sends the results back to the EFAs. So that way you can maintain all of your test scripts within EFAs. Run it, select the runner you want to use, and then you can run the test scripts in the cloud using our cloud runner. Or you can use it using your local runner that you have registered on your personal machine. Once you run it, it will now send those results back to our dashboard. And now you have a dashboard that you can use and share with the project. And given the health of the application or the health of your pipeline. So there's three ways you run it. Using the OpenFast jar, using the actual Maven runner that's tied to a Maven project, or using a GitLab runner that you can also kick off your pipeline. So we kind of thought through those three scenarios, and most likely those three scenarios should cover whatever way you want to run your task.

Nice. That was like another downside of windrunner. I could never find a developer to install it on their machine. But it sounds like if you had a development team, you just tell them the maven command or the git command and they could then run the test just like they're already running their code.

Yes. Actually what you do is you just. Once you register the runner on your on your personal machine, you go into E fast and when you select the test suite you want to run, you select the runner that's registered. So the EFAS automatically detects the runner that's running on the local machines. And you can see the status of that runner, whether it's online or offline. And if it's online, it will show up in a dropdown. You select it from the dropdown, it would execute those scripts locally right there on your machine.

Awesome. So keep going back to old times. But I'm thinking of WinRunner Test Director. WindRunner failed. I could code it and then I could see in test Director, like I can see a video replay. I could see all these things on why it failed. Nowadays, like using something like Fast Refast. You mentioned dashboarding. Is that one of the ways that maybe you can help understand when a test failed? Or like, what are some of the ways that using Fast Refast can help you understand why a test failed?

Yeah, absolutely. So fast itself FAST is the engine is built on top of Selenium. It creates an HTML report that gets created directly on that machine. And that HTML report will show you step by step. It also includes. You also have control over what screenshots you want to take in every step. So as you're building out your Test script, you indicate, okay, I want to capture a screenshot on this step. So when you do that, it shows those screenshots in the HTML report. When you open it, that same report gets built into EFAST as well. You'll be able to view it from EFAs. So if you're running your test scripts in the environment where you have VMs and whatever reason they want to set up the scripts to run in a centralized VM that you don't have access to, then you run it through EFAS and that dashboard gets updated with the same HTML report with the same screenshots. But we added another feature. We had another capability that we found very helpful and it's kind of going into the AI stage of things. But right now in this manual we have a feature called where it's Execution Run Analysis. And in this feature here, and I got this from a project that I was supporting from one of the clients I was supporting, we found is that if we track and understand why our scripts fail, if we log and we kind of catalog the different types of failures that happen, can catalog how we resolve those failures over time, we'll get an understanding of where the pain points are. We're going to understand enough what we need to do to fix, you know, to fix it long term and what things that we thought fixed it did not fix it. Right. So we added this capability into EFAs. We call it Execution Run Analysis, where you can now actually, you know, add notes and track why your scripts fail. And over time you can go back and look at that and if a tester, you know, test script failed, they can go back and look at a history run and see, okay, this is how we fixed it in this other script here. And what we plan to do in the future with that, Joe, is, you know, we're going to make it smarter. You know, we're going to understand the failures because we capture every single error message and why it failed. We capture every single exception message that gets sent. So we'll be able to understand it and start building some capability around, you know, around that.

Once again, when I was working for a team, I know when a test failed, team fixed it and then a few runs later failed again, same exact error, and you're like, oh, what did I do to fix it? So we had a knowledge base. You'd search the knowledge base. It sounds like something kind of like that, but more smarter. That's a. Sounds like a great solution for sure.

Absolutely.

You mentioned something interesting, using Selenium under the COVID so like we said, we're not dogging Selenium. Selenium is awesome, but you need to build a lot of infrastructure on top of it. So it sounds like you just walk us through what we mentioned, a few terms then Selenium, you mentioned fast. You mentioned E Fast. Can you mention maybe the different parts of the solution? Maybe how give an example of how it all works together.

Yeah, sure. So by the way, efast is built to support multiple automation tools out there. You know, it was originally designed to support uft, it still supports ufc. It also supports rft, Rational Robot, you know, Rational, Rational tools. We're adding all of the various tools out there. We went with Selenium as our base because it's free, because it's open source. So what we, the way that it works is efas. Think of EFAS is your test automation management tool. This is where you go log in and start creating your test artifacts. Where you start creating your, what we call universal steps. That is the first thing that you need to do, right? It gives the tester the ability to actually start creating test case shells. You know, these are the steps, these are the objects that I need to interact with in the application. So you build out those universal steps and then the next thing you do is you want to group those steps into what we call it a functional step. The classic example of that would be login. You know, you have to enter username, enter a password, click the login button. So you'll group your universal steps into a login functional step. Right now you have a reusable login step that you can use throughout any of your test scripts. Once you build your functional steps. Now you go and build out your test script. Your test script is a group of functional steps, you know where you want to execute. For example, if you want to build a smoke test, you'll go and build all the functional step you need to execute that smoke test and you'll add those functional steps to your test script and then you build a test suite is a collection of test scripts. So EFAS is your test repository in a sense. It allows you to build out and automate all your test cases in a very user friendly way in a non coding way. We have another cool feature that we call object map. This builds on top of what UFT did with their object map. So we try to make it a little bit more configurable in a way where you can configure however you want to build out your object map regardless of what tool you Decide to use whether you're using Selenium or whether you're using U of T or whether you're using rft. You can now build out your object map and identify what pages you want to interact with in the application. How do you want to organize those pages? And you go and add all the attributes for those different objects. So once you have that object map, Jill, you now have the footprint to start automating your test cases. As you're manually walking through your test case. So you're walking through, executing your test case, you're building those test case shells out and you're building out the automated test. So this is what we were thinking about, you know, when I say, you know, we're trying to be ahead of the curve, right? We want to have, you know, an automation tool that can stand the times of change. You know, Agile is the thing now, but it may not be the thing 10, 15 years from now. So instead of trying to automate the application, what we did is we automated the process in which you test an application. And that way, regardless of what technology you're using, you can still maintain and build your scripts the same way. That's the test automation management side of it. We purposely designed the FAAS framework to be separate from efas and we did that with the intention of that one. We wanted to be able to support any tool that comes out there. Selenium is a thing. Now Cypress is slowly starting to take over, right? And you know, some other open source frameworks have probably come out there. So we kept the framework separate from the two. And what we wanted to do was we wanted to provide our community with a framework that they can use right out of the box. So we decided to use Selenium for that framework where you can go ahead and download the actual framework. It's a keyword driven framework. The lines is probably, I would guess probably no more than 100 lines of code right out of the box. And with that, we know that you can probably automate about 95% of your application without adding any custom code. But we also know that we have these developers, right? Developers, they want to also be able to automate. So we wanted to provide a framework that developers might want to roll or even test automation engineers. They want to roll a sleeve up and they want to start customizing, you know, the framework. They want to add some new capability, you know, to fast and some things that we haven't thought about yet. So we wanted that framework to be separate so that they can customize it. However, they need to customize it, but they have an actual ui, a user interface that they can roll out to their team and say, all right, guys, I just added these new custom actions, and now you can go ahead and use these custom actions and build them into your functional steps. And they can very well collaborate with their team in a much organized way where they're not having these duplicate methods or these duplicate actions in these duplicate, you know, libraries. So that's why we designed it that way. We purposely wanted to have the framework, the actual code base, separate from the ui.

Nice. So which part of this is open source did you say fast was? Open source?

So fast. So fast. We have a framework called Open Fast and that is open source.

Yeah. Do you also have a cloud solution? I think I was looking at your site. Is that something you're working on?

Yeah. Efast is the cloud solution.

Efast is the cloud solution. Cool. Cool. All right, Cool. Okay, Marcus, before we go, is there one piece of actionable advice you can give to someone to help them with their automation testing efforts? And what's the best way to find contact you or learn more about efast?

Yeah, So I will say the actionable advice I would give someone is, you know, keep your tester's mindset when you're building out your automated test case. Cause ultimately what you're trying to do is you're not trying to automate the application, you're trying to automate the testing of the application and you're trying to. The end goal is to find bugs. So always keep that tester's head on when you're building out your automated tests, when you're building out that automation framework, because that, in the end, is going to give the testers and the team the most flexibility in covering whatever scenarios and conditions you need to cover.

Awesome. And the best way to find contact you or learn more about EFAST, go.

To qcefast.com and you'll see courtconsulting.com is our actual corporate site. You'll learn more about overall what we do. And in qcefeds.com go out there, create a free project and get busy with, you know, building out and joining the automation area community.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode, head on over to testguild.com a413. 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 Labs 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 awesomeness. 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.