Leveraging AI for Robust Requirements Analysis and Test Generation

Foreign.

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 we're going to have a special treat for you. It's all about leveraging AI for robust requirements analysis and test generation. This is an approach I haven't seen before, if you don't know. I have a new show and I stumbled across this awesome tool that leverages AI for requirements I think you definitely have to hear about. So I was lucky enough to get Scott, who is the head of this company, Agile AI Labs, which has the solution that can help you leverage your defects across your software delivery life cycle as well as significantly increase the productivity of all your Agile team members. It really does a lot of cool stuff. Scott has been testing software for over 36 years, so he really knows this stuff. And we also have John Smart joining us. You probably know him from previous Test Guild podcasts and conferences. He is a BDD specialist, automation testing specialist, and he's also the founder of the Serenity Dojo, an online training platform for testers who really want to learn world class agile test automation engineering. And he's also the author of what I think is the best book on bdd, BDD action and the creator. I always say this. What is my favorite framework in the world? The Serenity BDD Test Automation Framework. That used to be my go to framework when I was working full time as an automation engineer. Really excited to have both of you on the show. You don't want to miss it. Check it out. Hey guys, welcome to the Guild.

Hey Joe.

Thank you.

Yeah, good to be here.

I'm really excited to have you, I guess. Scott, let's start with you. You know, as I was mentioning, I'm always looking for new tools and things to report on my new show and I came across something called Spec to test AI. So anytime I have a founder on the show, I'm just curious to know why did you create this particular tool and what makes it different than maybe other other tools that are out there?

Yeah, I mean, honestly the reason why we create so obviously myself, but the team and I created the tool is because we've got a lot of passion for defect prevention. The team that we've assembled as part of the company, pretty much everybody in the company has 25 plus years of quality engineering and testing experience. So they've, along with myself, have really thought about how can we make a difference using AI and make real change, make a real difference. And so what we did was, you know, during the genesis of the project, we thought a lot about looking across our experience, as many of us have done, for example, consulting. And where did we make sort of the biggest bang for the buck? It was almost always in and around helping companies, helping organizations prevent defects. Right. Even though we're all passionate, we're pretty much all testers, but preventing defects always had that massive roi. And so we really felt like this is an area where, hey, not a lot of people are focusing on, certainly not a lot of tools or platforms today are focusing on really shifting left, using AI to actually do that effectively. So we, we said, you know what, this could work. And yeah, so here we are months and months later and it's working.

Yeah.

Awesome. And John, how did you get involved then? I know you're a BDD expert. Did this come across your radar and you're like, oh, this is a good idea. Like, how did you get involved in this as well?

Well, I often get asked to take a look at AI and test automation tools, and I do, and often I don't say anything because I'm a little bit underwhelmed by them. And when Scott reached out and sort of explained what he was doing and showed me spec.

Where it was an early version, but even at the time showed me through the evolution of the tooling, it really blew my mind away. And also just talking to Scott, Scott felt like my long lost brother from America, because we were thinking in exactly the same way. This whole idea of that you don't actually get the leverage from automating tests after the fact. The real bang for your back is when you're helping teams collaborate and discover and align their thoughts early on. And there's a lot of problems. Teams see massive problems all the time. Even now, aligning their thoughts and getting their ducks in a row, so to speak, making sure their requirements are consistent and getting that communication flow going. And a lot of that comes down to expressing the requirements well and troubleshooting them initially and asking the right questions and applying AI at that early level just makes so much sense. So the product just really clicked.

All right, so we keep saying it's, it's shifting almost left to the requirements. So can you give it a small example what we're talking about? Mostly when people hear AI, they think of gen AI, where it just creates the script for you. But this, this I think is a lot more, it's a different approach. So can we talk about the requirement type of approach that this takes?

Yeah, I'll take that. So one of the things that the platform does is it really does drill down and analyze user stories or requirements. Right. And along with that, it's not just the story itself, it acceptance criteria. So for example, we produce 32 different measures from a single user story. So we're measuring 32 different attributes of a user story. Now we use very popular frameworks to do that, like invest, like smart, and we have a couple of other custom frameworks that we've used. But that's really where the first, like when people first, you know, jumped in the tool or they're getting their first demo, that's usually the first aha moment. It's oh wow, this thing is really different because, you know, the platform is literally interrogating my user story, telling me where it's good, where it's bad and giving me really helpful AI based, but really helpful advice in terms of how can I correct some of these problems. For example, ambiguities, right. That's one of the biggest things that the platform points out. We have a seven point ambiguity framework. So seven of those measures, seven out of the 32 that I mentioned, are very specific to ambiguities. And the platform actually not only tells you that, hey, you've got some ambiguity problems here, it fixes them for you automatically. Now it tells you exactly what it's fixed, tells you exactly what it has gone through and changed so that the user's always in control, but it does that for you automatically on your behalf. So yeah, awesome.

So John, BDD expert, you wrote the book on BDD in action. Can you explain how this type of solution then can help make someone's automated test better?

What I find in this solution, this approach, is that it? We like to call it the fourth amigo because it really is an iterative collaborative approach that forces you to go through several steps and to reflect on the requirements and clarify them if they need to. It points out, hey, here are some issues you probably should address. Here are some things that aren't clear. Are you sure this is what you meant? And you work your way down through. You don't just say, okay, here's a requirement, give me a test script. You worked your way down through the requirements to use the stories to acceptance criteria. From the acceptance criteria you can identify test cases, you can identify, you can go to given when then if you want. But the real value, and that does help to be clear. But the real value is all that whole flow of getting the step by step approach and being able to collaborate and iterate on that and getting feedback at each stage. Because what I find with chat gpd for example, I've done a lot of experimenting with that and it's getting a little bit better. But you give it a user story and you ask for some acceptance criteria or go off on a in a direction that it chooses, that may or may not be the direction, but once it starts it's very hard to stop. Whereas this approach where it's really pointing out the things that you need to improve at each level and with all these different criteria that you don't normally get. So from a BDD perspective, it really is a great way to help collaborate around those requirements. And that what I find is, and this is what I find when I'm coaching teams, the biggest signal way to get teams doing better automation is to get them to do better requirements. After that, the tooling's natural. We work in an industry with smart people. Once you figure out the requirements and show them how to write good acceptance criteria, the rest flows really naturally. You have a few conversations and they're off and running. But if you don't show them how to get the requirements or don't help them in that early stage, it's much harder and they can get stuck in a rut and get themselves into a lot of trouble. So the automation perspective is really what you're leveraging that power of collaboration early on and that's where you get the benefits.

So it sounds like it really embraces the true spirit of what behavior driven development was created for. And that is the collaboration, the communication. A lot of times tools come in as automation for us, but this sounds like it's literally BDD the way they meant BDD to be used. I don't know, Scott, if you agree with that statement or not, but yeah, absolutely.

It's interesting because, you know, I think when John and I first started collaborating, you know, even I'll admittedly say I'm not a BDD expert, I even was able to learn some really tenants of tenets of BDD that I've been able to help influence back into the AI training. In fact, John and I recently collaborated over making some enhancements to some of the BDD output in the tool. And I mean, as you know, he's got great insight and a great handle on all of that. But it's interesting, you know, I think in the Realm of bdd, what you don't know and what can be done. Right. Because it is really of such a powerful, powerful mechanism. And when, you know, when we can build at least some of those best practices into an AI tool, build some of those trainings into an AI tool and help at least automate some of that process, it really is a ton of value. So, yeah, I mean I, you know, as you know, I, I absolutely love what John's talking about. Yeah.

So this is something I think people actually need to see to really appreciate it. So I know you do have like a free trial, but I'm going to try to audibly because it's just video and also talking heads only might be hard for people to envision. So how does it work? Someone has a user story, they feed it into your solution and then it automatically runs it against creates test cases. I think it has edge cases, it could come up with mathematical models, test coverage. I think it even has like traceability as well. So how does that all work? Like, can you just say like, I still don't know if people are hearing this, they still get the gist of what this is doing.

Yeah, there's. And by the way, people, you know, can jump over to our YouTube channel, take a look at it as well, Agile AI Labs. But because we've got a number of videos out there, some of them are 30, 35 minutes long, people can literally walk through. But what it does is there's really two major components to the tool. A lot of what you just spoke of is on the testing side. But what happens first is the user story gets distilled and measured. So that's sort of what we call step two. That's all of the analysis around the requirement. And we do things like not only provide them with all of that feedback and advice, as I mentioned, and give them those 32 measures, but. But we actually change the requirement. We enhance what we call enhance the requirement. So that's done automatically on the platform. And then we generating things or assets like security requirements. We have models around helping to generate that. We step through and have other features that do things like cross analysis from a user story perspective. So for example, we don't just look at your user story, we look at the other adjacent user stories that have been defined in your project. That's really helpful when you sort of break out of the mold of the existing user story you're trying to analyze and then look across, kind of do that adjacent scan. So we're doing things like that on the analysis side but then we sort of graduate to, you know, basically what they do is they look over all that material and then they basically click a button and graduate to the testing side. And the testing side has, as you mentioned, functional test cases, happy path test cases, edge negative security test cases. We're doing a lot with security right now. So, you know, they get a lot of pointed OWASP security testing advice as well as advice around OWASP's out. So in addition to that, they get, as you mentioned, the mathematical models, they get kind of a view of, from a test case perspective, what is their coverage. And when we talk about coverage, we're talking about coverage and traceability back to the requirement. Obviously the tool knows nothing about their code, but we're tracing that back to the requirements. So those are some of the things that we're producing. There's a lot actually in the platform.

John, is there anything that you found that, that it's producing that you thought, wow, that's really neat compared. Like you said, you were underwhelmed from all the solutions, but this one, you're like, wow. Like this particular feature I think is the killer, killer feature.

It's the layering that I really like. The fact that you start with a high level requirement, you break it down. It helps you structure your thinking around the requirements. And at each stage it'll give you feedback about the quality of the requirements that you write. And so you come up with a high level of feature, you can break that down into stories and it gives you feedback on those stories. So most of the tools, they just started. Okay, I'm going to take a piece of text, a user story or whatever and spit out some acceptance criteria or spit out some test scripts or, or not even just let you enter the test scripts. But they don't help you actually think about whether you're writing the right test and whether you're coming up with the right requirements.

Awesome. All right. So, you know, I guess I'm why I'm hopping on this is traceability. I used to work for a health care company and also an insurance company, and traceability was really critical for like audits like the FDA come in. And it was always hard to say, okay, we ran these tests and they, they go to this requirement. And anytime a requirement changed, we had to make sure we had the right tagging for the test. Can this particular solution help with traceability, especially for an audit? Is that something, is that a use case you would see or think, would this be good for.

Yeah, that's one of the assets that we focused on and that gets automatically produced. And basically what we're doing there is we're creating a table, if you will, of all of the acceptance criteria, in other words, all of the points that must be interrogated. Right from a testing perspective. And then we're. We have a different AI model that takes all of that data, all that information, and compares the output test, the generated test with that. And then it draws conclusions. It summarizes whether or not there is 100% traceability. If there isn't, and sometimes it will not, it will tell you, hey, you've got, you know, 96% traceability, here's your gap. And so you want to fill that gap in, but it provides, you know, paragraphs and paragraphs around and detailed information around all of those points of traceability, which is really quite helpful. Again, all of that gets generated within the course of two and a half to three minutes, in addition to all of the other assets that I mentioned earlier. So it's one of those things that it's such low touch and there's so much potential value that people can get out of it that it's probably one of the bigger, at least on the testing side. It's probably one of the bigger feedback points that we have been hearing in terms of. You know what? This is really quite useful. This stuff would take me 25, 30, 40 minutes to write. I get it automatically with the output of all of my tests. You guys are saving me a ton of time.

Yeah. What happens once you get that output, though? Is it automatically going to create automated tests for you? Is that like another tool that would come in and read this to do that, or is this not necessarily just for automation? And also it could be someone that wants to use exploratory testing, say with security. They may not know how to use these tools with security. Can it go through these user stories and that much detail where they can perform them and by manually?

Yeah. So what the tool does is it provides very detailed manual test cases. Right. That is sort of our biggest selling point, if you will, of the platform. Our test case generation engine is very mature. The reason why I say that is because we use different mathematical models to actually generate tests. So what you're getting is the base, you know, the foundation of all those manual test cases automatically generated. What the tool does, what the platform does is also automatically generate a starter automation test, automation script. Right. So what you can do is you can choose your tool, you know, selenium, appium, etc. Whatever you want, robot and choose the language that you want the script output in and it will do it right. There's, you know, and basically what you get is every single functional test and every single step in those functional tests are coded in that, what we call sort of that base template, Selenium output. So potentially you're going to get a couple hundred line. In fact, most of the time you usually get a few hundred or 2, 3, 400 lines of code that mimic step for step, exactly what you see in those manual test cases. Again, that becomes a huge time saver. However, that's not, you know, as you know, that is not all that you need as a test automation engineer because you need, for example, exposure to the dom. You need to be able to automate all those low level components and you cannot do that unless you have exposure to all of those web elements. Now our tool, the platform doesn't have that exposure. So it's really just a starter framework. And we, you know, we need to emphasize that what it produces for you is a starter framework for, you know, again in Selenium and Appium and Robot. But it helps. I mean, you're going to save multiple hours again as a test automation engineer just by having that produced for you automatically. But of course it's not going to get you the whole way. We do have partnerships with other tools right now that actually allow us to take our manual test cases, which are very rigorous, very thorough, feed them into their tool and in one click you can generate automated test scripts. No code, low code, automated test scripts. But our tool itself doesn't do that. It only brings you so far.

So John, you're the BDD serenity expert. Like how would you use this output? Have you, are you able to convert it? If you're in your dojo and you're teaching your folks about BDD and you say, hey, here's how to get better requirements, here's some output. Like how do you then convert that into an automated test?

I think the beauty of it is that it actually produces half decent gherkin scenarios as opposed, which is what a lot of the tools struggle with. So the qual, I say half decent, tongue in cheek, it's actually really good. So really nice gherkin scenarios from those acceptance criteria. And then the template, it's just template Java or JavaScript or Python or whatever language you can use, you can then fill in the gaps. So I would, since it's so Scott was talking about Selenium, but it's very minimalistic code, you can fit anything you want into it. It doesn't actually commit the. It applies. So we'll talk. Scott was talking about some of the BDD best practices and whatnot, and the gherkin that it produces does stay at a business level, does keep things at a implementation agnostic a lot of the time, which means you could be automating the UI or you could decide to go through an API depending on the requirements that you're working with. But after you have that gherkin scenario that saves you basically the one layer you don't, you can then take that. You'll need to tweak it. I mean, they always need to tweak, tweak the code that you get. But certainly like you get a few hundred lines of starting code which compiles and works and you can use as a starting point for your code and then it's relatively easy to take that away and then just start writing your tests the way you normally would.

So is there ever a disconnect like, I have the requirements, I then generate my tests in a different framework. Tests become stale and old, people modify them. They don't necessarily then trace back to the original requirements. Is there any type of traceability once it's out of the hands of, say, a spectatest AI? Scott? I don't know if that makes any.

Sense, but yeah, it makes complete sense. No, there's no traceability because we recommend strongly that people stay true to the requirements portion of the platform. And what that means is if you're going to go off and change your tests, we understand that, but if at all possible, and our recommendation is, you know, again, if you're going to enhance your test because you are missing, for example, details, maybe there's an edge case you're missing. It's not because the AI has missed it, it's almost always because we've proven this through testing. It's almost always because you did not provide enough details in your story to inform the AI that, hey, that edge condition is actually something I want tested. And so, you know, what we recommend is people try and stay true to keeping that linkage because as you know, requirements change, stories change, business needs change so often during the process that if you've got that linkage, all you need to do is come into the platform, click the button once you have a new business requirement, because the way our tool works is you're either putting, you're either copying, pasting the user story in or you're. We have a JIRA plugin, you're pulling your updated story directly from Jira So, you know, the business gives you a new story, you just click the button and you're going to get all the new analysis and then you click the second button. Now you're going to get all of your testing assets based on the change. And all of that just happened in less than five minutes. Whereas, you know, it would have taken them hours and hours to have to write that stuff by hand.

Nice. So if someone had existing user stories and requirements, they would run it through this. It also, I guess we alluded to it, it would point out gaps. Right. So like, say I had a, a feature, but I had maybe like one test covering it and I had one other feature, like a login that had 20 tests covering it would be able to say, hey, look, you actually should generate tests for this area because you have no, hardly any coverage on it.

So the way it works is it will inform you and actually create the tests. If you, for example, in your acceptance criteria you have outlined or in your, in the context of your story, you've actually outlined the fact that, you know, you've got feature A, feature B, et cetera. And there are these permutations around that feature that exist. Right. So with the AI will pick that up and say, oh, okay, well, you've got these permutations. I need to create tests for that. So it, the, the engine itself will do that automatically. But it does. It won't. One thing it won't do is take a look at your existing test cases, for example. Right? You can't, you can't actually feed your existing test cases in. It's not meant to do that. It's meant to. Everything we do, it comes from an enhanced requirement. Right. Our, this really the starting point of our platform is, you know that enhanced requirement that we were talking about earlier? Yeah.

Nice. So, John, I know you develop a lot. So when you saw this, is there any, anything you think like this is at stage one, but you can see a stage two. If they just did this tweak, is there anything that you could see added to this? I really could make it even more powerful.

It evolves so quickly. The thing, the new features are coming out all the time and I have been suggesting things. A lot of the, the interactive nature of it is something I like to see evolve even more. The fact that there is the. You can ask questions now, can't you? That's at each stage.

Yeah, Questions will get generated.

Yeah, yeah. So basically it's that sort of interactive approach that, that I really like to see and I'd like to See, enhanced. So that each stage you basically, like we said, we're calling this the fourth Amiga. You want it to play the role of the fourth amigo in a three amigo session and help you have conversations and enhance your conversations. And that's actually I work with a lot of teams that like from, well, not from the UK or the us. They don't necessarily have English as their first language and it's not necessarily an easy task to ask them to write acceptance criteria that are really well written, very clear and unambiguous and tool, that sort of interactivity where you can sort of propose a draft requirement, it will come up, hey, here are some areas you want to improve or this is ambiguous or maybe you. And then also, I don't know whether Scott mentioned that it doesn't just propose changes, but it proposes an enhanced version of the requirement. So here's your draft requirement, here's an enhanced version with the wording rewritten to make it a little bit less ambiguous or a little bit clearer, a little bit more complete. And that is a real time saver for like the teams in non English speaking or non first language, English speaking countries that may struggle a bit to get that sort of. Even if they can do it, it'll take them longer and this can really speed up that process. And that's interactive side of things that I'd like to see enhance even more.

So a lot of times when people hear AI, they think, I'm being replaced. This sounds more like an enhancement, like an assistant, a buddy that's going to help you find ambiguity and get communication. It's going to start communication rather than shut it down. Say, I did all the communication for you. Here's your requirements, here's your test cases, right?

Yeah, exactly.

Yeah, exactly. The way the platform was architected from the beginning is it is user centric, it's human centric. Right. And it's meant to be a productivity tool. It's never meant to be a replacement. And it's great because there are so many assets that get generated. You can, as a user of the platform, you can pick and choose what you want to focus on, what you want to use, what you don't want to use. There are points in the platform where you can just edit what the AI has produced. You're always in control as a user. You never have to accept any of the AI changes. But the other great thing about the platform is that we show you everything that has been done. As John was mentioning, you know, just a minute ago, there's an AI enhancement tab. Not only do we show you the enhancements, but we side by side, we show you your original requirement that you entered your story. And then right next to it, on the right hand side, we show you all the enhancements and we bold and highlight literally every single change that the AI engine has made. So you've got clear transparency always. And you feel when you're using it as a user, you feel like, yeah, I'm in control, it's a massive productivity booster. But I'm in control, not the AI. And we want to keep that going. We're big believers in sort of human centric AI.

Absolutely. And it seems like an encourage better testing. Like I said, I was, I was happy to see security test cases as one of the outputs. Probably a wish list. I know you're just starting, can't add everything. Like does it cover performance testing or accessibility testing? I know accessibility testing has been really hot the past year or so. Don't know if that's something on our moat.

Yeah, definitely on our roadmap for sure. Accessibility, yes.

Performance.

We have been thinking about it. We honestly haven't had a lot of clients who have come to us and asked for that yet, but it is, we're definitely open to doing something like that as well.

Scott, what are your clients saying? Like, so an unfiltered. They use the product like any case studies are like, wow, I knew this tool I created to help people, but I didn't know once it got in the wild it could do this and actually did that. Whatever.

Yeah, most people are wowed after the first demo, but once they've gone through a pocket, you know, the themes that we're hearing from a feedback perspective are, I didn't realize AI could be trained to do something like this. I had no idea that, you know, we could literally take our Agile process, introduce a platform like this and boost productivity across the rest of the Agile team. Because I mean, as you know, a lot of the focus today is on developer tools, coding tools, AI co pilots. Well, what about the rest of the Agile team? Right. What about your project manager, your scrum Master, your SMEs, your business folks and your quality engineers, your testers. And so that's usually what we're hearing back from the teams. We hear a little bit of it during the demos, we hear some of that wow factor, but once they get their hands on it, once they've done a POC and then move to a purchase, it's really great, great to see.

So, yeah, so I'm hearing it Almost like it's an Agile productivity booster. An AI Agile Productivity booster. Just absolutely bowling titles here for the podcast.

Yeah, yeah, absolutely.

It is, it's copilot for requirements discovery.

Oh, okay. Even better. Love it, love it.

That's good too.

Yeah, for sure. All right, John, I know you do a lot of training and I believe you have like a dojo. Do you actually use spec to test AI in any of your trainings? If someone really wants a hey, let me really try this with an expert in a real world scenario so I can learn it even better.

We do, absolutely. So we run both the Serenity Dojo, which is for individual testers wanting to get up to speed with Agile Test Automation. We do do sessions each week on BDD and we often use AI tools like spec for test and including spectatest. And we also run a tailored workshop for teams called the BDD Accelerator where we apply these techniques for each team for in their own domain with their own problems. And we do a lot, again a lot of work with AI tools and Spectra test in that space. So if teams are looking to adopt bdd, that's definitely a good way to go.

And how do they get there, John, to learn more.

So the best way is just to get in touch with me directly. So there'll be some links I presume under the webinar. But yes, there's a. The best way is just to get in touch.

So definitely check out all the links in the show notes and learn more. So Scott, one thing I know a lot of people are concerned about are, is ChatGPT leaking company secrets and putting all the requirements in ChatGPT and training it somehow and then it gets in the wild. Is this is your solution using ChatGPT in the background or is it. It's more than just ChatGPT. How does this work? I guess a lot of people be concerned about it.

Yeah, absolutely. We would never use ChatGPT. We, we're working with like literally some of the largest companies in the world right now, platform wise and security is absolutely imperative. So we absolutely stay away from public GPTs like that chatgpt any mechanism where there could be a security risk, security breach. You never want your company data, your IP information going into any of the AI training models ever. And I mean that's just an unforgivable offense from a corporate perspective, as you know. So yeah, we are highly, highly secure. Anything that we do on the back end is through a secure API mechanism and we keep steer away from any, any potential GPT like element. Yeah, Yep.

Okay, Scott and John, before we go, is there one piece of actual advice you can give to someone to help them with their AI BDD testing efforts and what's the best way to find contact you or learn more about spec to test AI? Let's start with you John. We'll end with Scott.

I think the biggest thing to get the so bang for your buck out of this whole BDD Agile test automation process is just to make sure you are having those conversations. And that's where spectatest really does shine, is helping people collaborate and have those conversations and make those conversations smoother and more productive, even if people are not necessarily in the same room. So the advice is make sure you're having the conversations.

Yeah, absolutely. Terms of learning more please. You know agile ailabs.com and our YouTube channel, there's some great demos out there, agile AI labs. But in terms of advice, what I would recommend is there's a lot of really interesting experimentation you can do with the public GPTs and I really do encourage people to do that, especially testing folks, because a lot of the experiments that you could potentially run may actually help you in your day to day. So for example, you know, I'm going to, I'm going to make a recommendation right now if you have the time as a test engineer. Absolutely. Try and experiment with some more of the advanced design mechanisms around creating a prompt. And what I mean by that is go ahead and try to, for example, take some sample requirements, make sure they're sanitized because there are security issues, but take some sample requirements from your, you know, from your day to day job and experiment with building some of those prompts up in terms of potentially trying to produce test cases. You'll get, you know, I think you can get to the point as a test engineer where you may actually be able to produce some interesting results and useful results that would likely help you in your day to day job. So you know, I'm at heart, I'm an engineer, I love to experiment and I absolutely encourage people to experiment. This a lot of interesting things that they can generate just using the public GPTs. Yeah.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode head on over to test guild.com a492 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@test guilds.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 test guild.info and let's make it happen.