Learning Journeys for Testers with Mark Winteringham and Richard Bradshaw

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. Today we'll be talking with Mark Whittingham and Richard Bradshaw all about learning journeys for testers and all other kinds of Ministry of Testing awesomeness. If you don't know, Mark is the dojo boss Administrative Testing. He teaches a lot of aspects of software testing and he supports and curates testing training from others in the testing community. He also is the author of the what I'm calling the number one book on API testing called Testing Web APIs published by Manning. And I'll have a link to that in the show notes. So you definitely want to check that out after you listen to this all the way to the end. And special we have the boss boss himself joining us, Richard Bradshaw, AKA the Friendly Tester from Ministry of Testing. Richard is a very experienced tester, consultant and generally a friendly guy. He shares his passion for testing through consulting, training and giving presentations on various topics related to testing and automation. And so you probably heard of him for sure and seen him at multiple conferences. He, he has a bunch of experience. Really excited to have the two back together again on the Guild to share their experience and to go over what I think is a really unique.

Development in the testing space I think you all need to know about. So you want to make sure you listen all the way to the end to learn how you can up your learning journey as a tester. 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 and 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 can take your brand to the next level. Head on over to test guild.info and let's talk.

Hey Mark and Richard, welcome back to the Guild.

Hey Joe, how's it going?

Hey Joe.

Great to have the super friends back together. I think that might have been the last episode we did. That was years ago. So great to have you both here again.

Yeah, I was wondering if you'd remember the super friends thing.

We're pretty much married now. Right.

Very hard.

Yeah. Testing spouses now, so it has been.

A while and I usually botch bios. Is there anything I missed in either of your BIOS that maybe you want to share more with that you've been working on or anything I may have missed?

I suppose the big thing for me.

Mark's got a new job.

Yeah. I'm now the ops boss at Ministry of Testing, so.

Ops boss?

Yeah, much more. So kind of focused on sort of helping the team in day to day operations and helping Richard get his vision actualized. Oh, such a horrible word.

But.

Keep things moving is how I view it. Joe, you know he's a thousand things you do at the Guild. Right. Trying to keep all those things moving.

Yep.

For sure.

That's Mark's job now. I'll do ideas. Mark keeps everything moving.

That's great.

Yeah. Well, we've done it with ait so we thought let's do the same for Ministry of Testing as well. Seems to work well.

Yeah. I get an operations manager that's changed my life, so I'm sure that's exactly the same role.

That's it.

Yeah, exactly.

Yeah, it's pretty much that.

A good move.

Not much has changed in my area apart from I spend half my week as a Ruby on Rails developer now. So.

Yeah, no, I was seeing that. Why is that? Just to keep up? To keep your hands dirty or.

Few things really. Number one, the website needs a lot of love and budget wise, you know, still recovering from COVID and that kind of situation, so. And number one, I can code and I love coding and I'm not. My day to day job doesn't involve coding really. So I thought, you know what, I'm going to jump back in and do some building. So I pair with our dev boss quite a lot of the week now and get to code. Obviously it's not sustainable. It shouldn't be. I don't advise CEOs spend all their time coding but right now it scratches a niche and it helps the business. So. Yeah.

Awesome. Very cool. So I think, you know, I like to set the stage. I just assume people, everyone knows who Ministry of Testing is and I was kind of surprised when I actually caught up with Mark at Selenium conference this year and our booths were next to each other. That was eavesdropping, as I always do.

Yeah, we saw you.

There's a lot of people saying what is Ministry of Testing? I know people that don't know a test guild but Ministry of Testing. I just assume everyone knows the Ministry of Testing. And so before we even dive in, maybe let's start off there in case someone's, you know, just listening in for the first time. What is Ministry of the Testing?

I'm waiting to see. Mark, it's really hard to explain.

We basically call ourselves a professional community or community of testing professionals, but really it's a community that's open to anyone who has to do or has to do software testing as part of their role. So we specialize in raising awareness of software testing, skills, techniques, companies, events and we do that via website, our platform. We do it via conferences around the world, our conferences Test bash and we have online conferences very similar to the ones that you do yourself at the Guild. We exist, the motto is co creating better testing. So that's why we exist. We want people to be doing better software testing no matter what their job role is. And we exist to bring everyone all the best awesome stuff that's taking place out there in the industry.

Nice. And you all have been around for a while though, right? 2005, 2006 maybe, I'm assuming. I don't know. I remember seeing you really early on.

2008 for software testing Club and then Ministry of Testing I believe was incorporated in 2011. So yeah, and Ministry of Testing had its 12 years so yeah, it just rebranded and well it was two businesses and we renamed it but that was before my time as well. But yeah, now it's been going strong and like I said, I'm really happy we got through Covid and all the, you know, all those issues. So yeah, trying to push on now.

Mark, how'd you get involved in Ministry of Testing?

Similar way as Richard I think. Actually like we met at one of the first RSTs that Rosie, who is the founder of Ministry of Testing she put on and there was some very friendly non bearded guy who was Quite chipper for 9 o' clock in the morning which now that I know a lot about you Richard, you clearly were just having a good day.

So we met briefly there. But I think for the both of us, which kind of feeds into all this learning journey stuff that we've been doing, we both kind of went off, lived our lives, upskilled ourselves, came to realizations, started blogging, started talking, speaking and doing workshops and then through those conferences and stuff we met and we started doing our automation and testing stuff and that was Richard moved over to boss boss role. Around that time I was doing software testing clinic with Dan Ashby and Richard basically approached us and Said, you know, bring the two things in more closely. I was already doing like loads of courses by that point, online courses and things like that. So when the opportunity of the dojo boss role came and it was someone with that they need someone with domain experience but also with production experience, yeah, I jumped at it. So, yeah, I've been with BOT now for almost five years, which is like the longest job I've had for quite a while. So, yeah, and then I moved to the ops boss stuff two years ago. Two and a half years ago, I think.

Awesome. So it's great everyone noticed that you both started off as hands on testers. You both are still hands on testers. So it's a community by testers for testers, similar to Test Guild as well.

Yeah, absolutely, we both. And that's one of the reasons why I mentioned doing the Ruby on Rails stuff, because it's keeping me. I'm testing my own work and I am making so many mistakes that we used to catch as testers and we'd be like, how did the developer do that? And now I'm doing it all day, every day. But the website similar to yours, it gets tested by testers. So as soon as we make mistakes, people, people come and tell us. So.

So, you know, Mark originally contacted me, said, hey, we have these new learning journeys we want to dive into. So I was like, okay, that's all he told me. So I'm just curious to know, hey, what? I don't even know what a learning journey is. So what is a learning journey?

That's a great question. It's one we've been trying to practice as well. So essentially it's like a learning path. We're calling them journeys because the way that these new learning journeys are set up with me are basically taking you on a journey of learning. So the learning journey is based off our open source curriculums, I believe that Mark spoke about as well at the Selenium conference that you mentioned earlier. So the learning journeys are backed off the open source curriculum, which is the automation, engineering, testing. So they're off the back of that curriculum, which over 140 people contributed to. So we built that curriculum as a community. We did it all in the open, all in the public. And that curriculum is now open source. So anyone can take that curriculum and implement training against it. You know, for example, the Guild could do it, other certification bodies could take that curriculum. And the idea is to have this living curriculum that MOT will be sustaining. And then the learning journey is our implementation of that curriculum. So it's over 125 lessons. I think now, Mark, it might be more than that.

142.

142. Okay. So it's significantly bigger than a course. You could arguably view it as 12 or 14 courses in one. But the reason why we're calling it a journey is the whole educational bit of it is narrated by me and Mark. So me and Mark, weaving you through. And this is one of the unique things of it, weaving you through existing content. So that could, that could be a guild talk, it could be a YouTube video, but we're going to send you to that video and explain why we want you to watch that video. And then the next bit of that lesson might be some original content by myself and Mark. So we want to start reusing content that exists in the community because there's so much good stuff yet, we're always reinventing the wheel. So the idea is that me and Mark take you on these journeys based off that open source curriculum. And yeah, it's. I said it's 140 odd lessons long and it takes you from absolute nothing to all the way to go through context, strategy, goals, plans, picking tools, implementing the tools, maintenance, using, actually utilizing automation and yeah, the whole shebang.

So where can people get that curriculum? It's open Source Design, Git, GitHub.

It's not, it's currently listed on the club, but there is a link from the learning journeys to it. And hopefully in the coming months we'll have a proper curriculum page on the MOT website because we're also currently building the Junior software tester as well. So that's the next one that we're doing in the process.

Yeah, so it's so big, it's sort of trying to. And because another aspect as well is that we want to encourage feedback and maintenance of this open source curriculum as we progress. As the industry changes, as new people come to the community and share things, we want to encourage people to give feedback and help us update and tweak things. So we want to make sure that it's laid out in a way that's sort of engaging and sensible to kind of interact with as well. So, yeah, that's what we're sort of trying to get done, but obviously we're trying to get 40 other things done as well with two devs. So, yeah, the hope is that we'll have that sort of in a nicer form soon. But yeah, as Richard said, it's on the club. We've got it all sort of available for people to look at stuff. I'll share a link with you and we can put it in the show notes.

So what inspired you? I know in the test community there's a lot of people that are like against certifications, saying it's garbage. But this sounds like something that it's not a cert, but it's more like, I guess it could be like assert curriculum if someone applied like you said, Richard. So where did this come from?

Yeah, well, if I asked you the question of do you know who's behind ISTQB Foundation? So do you know the people who design that syllabus? Most people probably don't. I can tell you it's a bunch of people that aren't very active in the industry anymore. They're very active within the ISTQB space, for example, but in the wider industry not so much. So the idea was to start having curriculums that are built by the people doing the work. And we happen to have expertise at Ministry of Testing with our Sarah Deary, our learning boss, who knows how to build curriculums. So we said why don't we build an open one that's clearly visible, can be hopefully become kind of the standard for the industry for teaching against. But yeah, the idea is that it's just more open, it can be critiqued, it can be improved and it's a living certificate. Sorry, it's not a living curriculum. And I think to me that's just more appreciative of what the industry is and what our communities can create. And I think as a community there's always like, there's always been little secrets or passing around of this knowledge. You need to read this blog, you need to watch this thing, you need to do this, you need to do that. But it's never been curated. And the idea here is to put a little bit of a formal process on it, make it public, make it open source and then hopefully can start to produce more structured learning. So I think that's one of our goals as well. Like our learning journey. We believe it's very good, but also a lot of people don't know how to teach. So they have a lot of knowledge to share, but they don't know how to teach. They could just pick up our curriculum now it has very clear learning outcomes on it. So if you satisfy those learning outcomes, you will have created a very good piece of training material. So yeah, hopefully, I think that's is hopefully to compete, but it is also very different. So I think it's the start of having community based learning.

There's another thing to add as well. Like this has sort of been something that's been rattling around in my head for over a decade now. Although it started in the software testing clinic stuff, which was basically a bunch of meetups that did free software testing training. And then we started building a curriculum. And one thing I've noticed is that at that time, that was when Richard and I were starting to do more of our automation testing training. I was doing other training with my API stuff and I realized that the more I was doing of that, the less testing I was doing, the less industry stuff I was doing. And I think that's always going to be the curse of the instructor, or not necessarily a curse, but the paradox of being instructor, the more you're teaching, the less you're doing. And our industry changes so quickly and it's hard to keep up with it and stuff. Like I already see some technologies coming out and I always try and dabble but it's sort of a case of, you know, you can blink, miss it before something happens. So by developing it in this way that's open source is it keeps the curriculum relevant because there's no personalities behind it. Like Richard said, you know, it's not about an individual or a group of individuals behind it. It's something that is reflecting an industry that is very diverse. You know, some people are working in, you know, cutting edge crazy kubernetes, clustered machine learning madness in a startup and then someone else might be one of a hundred testers in an enterprise company somewhere else. The experiences they have are going to be, the expectations on them are going to be different. So we, you know, we collate all of that. We get some sort of kind of sense of like, you know, what are the commonalities? So one thing to say as well is like the learning journey has to be generic somewhat to address a wider audience. But it definitely hits all of the important responsibilities for anyone working in automation, like regardless of your role.

Nice. What I also like I say this about the test skill as well, is I think of Ministry of Testing as independent. So I mean, I'm not jogging sponsors. I love sponsors. I love thought leaders that work for sponsors. But you know, still they have their curriculums. But I always think there's some sort of motivation where it's really just kind of backhanded pitch for the product, which is great. We all need tools and solutions. But this to me seems more independent. So am I right with that as well? Where there's, you know, there's nothing no one else Dipping their hand in. It's basically community inspired. None.

Yeah, absolutely. You know, me and Mark arguably are the ones written it, but each step of that process was reviewed by the community. So at every point, every week we did a module and that went on the club and people critiqued it. They questioned our language, our words, questioned that things were missing. And we said, okay, well, we'll reword it and we'll include that. So as I said, there's over 120 people that have contributed throughout the whole process. We did it on demand so you could just log on and help. We also ran, I think over 15, 16 events where people, you know, got together and stormed ideas and started, you know, you know, we were saying, right, we need a module on creating an automated check. How the hell do you do that? And then everyone started throwing down their steps and then we added our steps and then we basically mixed and matched until we got where. So that's the idea, is that it is independent of me and Mark. The actual curriculum, if you look at it, it says organized by Ministry of Testing. But these are the awesome people that have done all the work. And in the future, when it's on the website, all those awesome people, it will link to all their profiles and you can actually see who they are, who is that person? And you can click on their profile and it'll be, hey, they've been a tester for 12 years and they currently work at wherever. And they've spoken at Test Guild and spoken at this conference. And you'll be like, oh, right, clearly that's someone who I can relate to. So that's kind of the difference. And as I said, we just wanted to be the curator. We just wanted to build the framework, manage the process. Bit like we were talking about ops at the start, but really it's the community that have actually done all the actual learning, set all the learning outcomes that are in there and listed the skills that they believe people need to do the job and they are the ones doing the job. So, you know, if they're telling us what they do on a day to day basis and we put that into our curriculum, the chances of you being able to get a job doing that is more likely. And that was one of the key things as well, Joe, that we forgot to mention. These things are designed for you to get a job. So if you take our learning journey, you should be at the position at the end of it to be able to apply for that job or move into that job or get promoted into that job. It's not just teaching you a little bit of the puzzle, it's the whole thing to have the job of an Esther or an automation engineering test, as we went with.

So how can you say that? Did you have like managers or hiring managers look at the. Over the curriculum said yes. If this person actually did this, then.

We did, yeah, okay, we did, yeah. So I'll let Mark tell you.

Yeah, yeah. So we looked at. So the initial phase was we looked at job roles. So, you know, just basically scouring job sites and looking at the roles and responsibilities. We interviewed automators, we surveyed automators, same with managers as well. And then, yeah, we went to the recruiters as well and spoke to them because it was really interesting. Like, there's definitely different perspectives of what's going on and what's required. So, you know, the recruiters are probably more explicit in what they're like asking for and what they're looking for, whereas on the other side, the managers are more like, I don't really care what tool you use, I just need these problems being solved. So, yeah, we got all these different sort of types of perspectives as well, which was, yeah, very interesting. Like, just as well to go back to what we're saying about, you know, the learning journey itself will be opinionated a little bit, but actually it's not necessarily. We're going to say you have to use tool X or tool Y or tool Z. It's much more sort of, you know, think about things on this layer, think about what sort of tools work for you in your context in that way. But what's helped with that is the fact that because we've set this curriculum out and we've identified outcomes, we. We're not arguing as a community about what things mean. So we're not sort of trying to decide what automation is. What we're trying to say is everyone should have an understanding what it is. And it's. We found if we all agree, like, what the roles and responsibilities are, that's an easier conversation to have than what does testing mean? Like, what is the definition of testing? Because then that's where things can slow down. So, yeah, and goes back to what Richard was saying is like, other people could take this up and they could have their own opinionated version of it as well, which works really well.

The key thing about the tools bit is really important because what we're doing in our journey, so we're doing C, JavaScript, Java and Ruby to start with, but the tools that we're deciding to show you in our Learning journeys, We basically just ask the community, what are the top tools people use for java to do UI, to do API, to do JavaScript, we're going to use those tools. But because the curriculum is open source, if Joe, you messaged me and said, oh no, I absolutely love this tool and you need to add this tool to the learning journey, I could just go to you and go, well, here's all the learning outcomes, here's all the code examples that we've built. If you're willing to build them all in tool B, we'll add it to the learning journey and then people can basically pick and choose what flavor of the learning journey they want to go through. So our plan is to teach one or two, but then have a link to other tools if they want to use this particular tool.

Nice. So just so people understand, the curriculum is open source, it's free.

Yep.

But the learning journey is the implementation of the curriculum based on your input, which is then is it paid? Is it, how does that work?

It is, yeah. It's a paid, it's a one off payment to get the learning journey. Right now it's super cheap, I think, depends when this goes out, but it's somewhere around the 400 pound mark and that is a lifetime payment. So as the curriculum evolves, we'll update the learning journey to match the curriculum. So it's a lifetime access basically to that learning journey. And yeah, it will go up to somewhere to around, I can't remember exactly, but somewhere around the 13, 1400 pound mark once it's at its full price, which is still cheaper than most, you know, three day training courses and boot camps and things like that.

So, so when you go to the learning journeys, I noticed like you said, you have something on automation engineering testing, C Sharp, Java, JavaScript and Ruby. It's all automation testing focused. So are you saying all testing is automation testing or will you then have certain testing paths or do you just assume that if you're a tester you're going to need to be trying to get into some controversy here? You need to be an automation engineer.

Yeah, not at all. We basically we've set out four or five curriculums that we would like to do, but as you know, running the guild yourself, you try and pick the one that's going to appeal the most. So we've started with automation, but we obviously, as you know, me and Mark, talk about automation and testing. So we went with automation Engineering testing as the title for that, but you could easily call it SDETs, automation engineers, whatever the one that we're currently, I'm guessing about halfway through Mark, halfway through the process for Junior Tester. So that one will have probably the closest rival to something like ISTQB foundation, something like that. So this is a basically, you know, entry level role into testing and then we're going to do testing for developers and managers, probably is the next two after that. So there'll be a lot of overlap between all these curriculums. Obviously, I imagine some modules will just lift and shift from one into the other. But as we said, it's more about the idea that we've gone for. And what Education Learning Boss suggested was that we focus on roles because that's how people get jobs, that's how people get paid. So we're trying to frame them around roles. So Junior tester, some sort of automation wearing hat. Obviously developers are doing far more testing than they've ever done. They've always done a huge amount of testing. But explicitly saying, I'm doing some testing, that's happening more and more and more and a lot of teams are obviously shifting to that way as well and then obviously manages that kind of aspect of the top down, looking on all these types of different testing, that will be the. Probably the one we will do after that. But yeah, that's why we started with it. Definitely not saying everyone needs to automate, however, the junior one does have an automation module in it because everyone needs to know what's possible. So they don't need to know how to do it, but I would say everyone needs to know what's possible. Who does the work. Context dependent. But not knowing that automation's a thing that's going to give you less options, it's probably going to hinder you. Whereas if you're aware, and we talk a lot in AIT about awareness, if you're aware, you're going to have more options to pick from.

Nice. So I know Ministry of Testing also has a PRO plan. This is different from that as well, correct?

It is, yeah. Yeah. So as Richard said, it will be a standalone thing. We may package Pro and the journey's up in the future, but the moment we're keeping them distinct because we're doing some work on Pro as well to sort of kind of elevate that as an offering as well. So, yeah, it will be a standalone thing. It's on sale at the moment, it will go up to full price in autumn. But the idea is, yeah, because it's such a big thing as well, it's, you know, taking us months to build. So it's going to take months to go through it as well. So it's. I think it's something that's made sense to keep it distinct because it is something that it is, because it is a journey, it's something that you're going to follow along. It's something you may treat almost like as a reference guide as well. You know, it's funny, like, talks about, like, writing, testing, web APIs. You know, I see this as another book in my mind, and that's partially because it's a mixed media. So it's not all videos, it's video, it's text, it's audio, it's code, examples, it's graphics, it's test bash talks, it's conversations, it's that sort of stuff. But the way that we've had to plan it, the way that we approach it, and I think it had to be built in the same way as writing the books and knowing what I know about these books now. And the process of that is that some people will read it to end to end. Some people will dip in, you know, some people will have specific problems they need to solve and they'll. They'll go to that part and do that bit and then go, oh, hang on. But that's interesting because they're saying that's connected to this bit and they'll move that way as well. So the whole thing is kind of, sort of, kind of built in that way. So, yeah, it made sense to keep it distinct from Pro.

It's quite an undertaking. You know, I wrote a book in 2013 on API testing using QTP. Right. And I use examples using an API that was no longer available. And so it had to be updated. Very difficult to update. I'm assuming with these learning paths, then it's going to be a lot like you could create something, then four weeks later to a month later you're like, dang, I'm going to have to redo it. It's changed. Are you going to be updating or is it. Are you trying to make it as evergreen as possible?

We will be, yeah. Yeah. We may regret these words in the future.

This is the current place we are right now, so.

Yeah, yeah. So we're currently. So we're building a test app to go with the learning journey of which we want to build it in every language as well. So I'm building the front end at the moment. So I think in some kind of basic timesheet manager or something like that, it may change. I might lose my mind. I've been at it for a week already. But then the idea is that there'll be different backends. So if you're in the C world, you'll probably be building with something in the net space. I'll probably build something to spring boot. Richard gets to play with Ruby, which makes him happy, you know, and then I'll try and do something in Node js. So we've got that. And then, yeah, we have the automated checks that we've got and the tools and stuff and the examples that go with that. You know, we will have to maintain those things, make sure libraries are updated. But again, this is where the community comes back in, because community will feed in like, you know, what are the new tools, what are the new approaches? And again, it's that aspect of the paradox. As a trainer, I probably won't pick up on these things because I'll be too busy traveling and trying to sell training and deliver training and stuff. Whereas, you know, we plan to set up this sort of kind of this cadence of, you know, people telling us of these new things that are coming along. You know, playwright didn't exist really when we started the curriculum. It hadn't been released. So, you know, it's. Those sort of things are going to happen as well.

Well, but we were laughing at the start, Joe, because we've been battling what to do, but we want to, want to practice what we preach. So if we're teaching people to automate on every layer and you're taking the C course, but yet the test app is written in Java, unit testing suddenly becomes complete, you know, car crash for you. Whereas if the whole app is written in C and you can run it all in VS code and you can stick it on Azure or wherever. Right. That's more realistic of someone in the C domain. So while we ideally wouldn't want to build four apps, but what we can do now is we can build four apps, we can put all the tests on the same pipeline, because pipelines are part of the learning journey in the curriculum and actually have a running pipeline that will run every day and it will tell us if the checks fail, it will tell us that dependencies are there that we need to update, which is exactly what we're teaching people in the learning journey. When we're talking about maintenance, we're talking to people about libraries, updating the automation libraries, but also the actual solution libraries for your product. All these things are updating all the time. And you need to be aware as an automation engineer that that might cause brittleness or failures. So therefore we're going to build pipelines exactly as we're teaching for this test product with all the relevant checks and also the learning journey Tech stack is completely custom. We built it ourselves. So within that as well, it'd be very easy to tell us that blocks of code aren't working anymore and they'll be able to automatically tell us and then we will get alerted so we can go in and fix it. The last thing I want, and it's the thing that happens a lot with courses, is for these code examples to quickly go out of date. So while they might be opinionated because they're written in the way I might like to write code as a business, we can't have them go out of date. So whether, as Mark said, that means the community get involved and they, you know, some people might be maintainers on the GitHub repos because again they'll probably the checks and the actual test projects probably will be open source because we're not, you know, yes, you can learn from reading the code yourself, but that's not why someone would buy a journey. They're buying the journey because they want to be walked through, they want to be taken on that journey. Yeah, it's a massive task and like we're both, we're trying to work out like the C1's the worst one for us because it's been a long time since I've dived into that space and Microsoft have been doing wonders, so who knows?

Well, yeah, it's like almost maintaining selenium bindings. You're gonna have these test apps and all these different versions, you're gonna have someone that maintains them. It's like a crazy undertake. And so kudos to you for sure. Okay, Mark and Richard, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing curriculum efforts and what's the best way to find you or contact you or learn more about this awesome new initiative? I'll start with you, Richard.

I would say the main thing I've always said, and the main takeaway is probably a failing check is an invitation to explore. So when your checks fail, whether that's for genuine failures or for flakiness, they're basically screaming at you. There's something for you to learn here. I'm behaving in a way that you don't expect. So come and dig into me and learn out. Why don't just like ignore them, rerun it, go and take the opportunity to learn and if you want to know more about me, follow me. Probably Twitter and LinkedIn is my most active now. So friendly tester on LinkedIn and friendly tester on Twitter and obviously all around Ministry of Testing, especially on the website and on the forum.

So yeah, I'm going to go for something that's kind of rooted in some other stuff that I've been working on and talk a little bit about like generative AI. So like there's a lot of conversation about automation and using generative AI to build things. I think the most value you're going to get out of generative AI if you're going to use it to help you with your automation is to focus on specific tasks. So don't treat your automated checks and that whole process is one big huge black box or one big blob. Think about the different things that you're doing, like how are you creating state, how are you interacting with the system, what sort of oracles are you doing, how are you interpreting results.

How are you building things like page objects, stuff like that. Using generative AI to solve those specific problems means that you're more likely to get something that you can use straight away rather than what I see quite a lot at the moment, which is people build stuff that's very high level, copy it across and then have to re edit the whole thing because the context of their application wasn't considered in that process. So yeah, that's my little tip for working with generative AI in automation at the moment in terms of contact same Twitter LinkedIn so Twitter's two bit tester Mark Winteringham on LinkedIn I'd be remiss if I didn't mention the book so Bit ly Test Web APIs if you want to pick up a copy of that as well.

I do have a book called Automation Awesomeness 260 affirmations to improve your QA and automation testing skills that include both Richard Bradshaw and Mark Whittingham. Definitely check it out. You can check it out@testskill.com getbook thanks again for your automation awesomeness. The links to evident value we covered in this episode. Head on over to testguild.com a462 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 and 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.