AI Testing Is Bigger Than You Think, 5 Areas Testers Must Own

Hey, so you probably can relate to this. You paste in your test strategy into your AI assistant, and the first thing it says back is, this looks great, you're brilliant, best I've ever seen. Feels good, right? Here's the problem: LLMs are the ultimate people pleaser. Paste in your test strategy and you'll get, this looks great, almost every time, which tells you nothing about whether your strategy is actually any good. Hey, welcome back to the show. My guest today is Swathi Sela, a principal software quality engineer and speaker with over 20 years in software testing, automation, and quality engineering. Swathi has been building a practical framework she calls the AI Testing Landscape, and it maps 5 distinct but overlapping areas where testers can contribute everything from using AI to augment their own testing, to evaluating AI output for trust, to governing AI development quality, to testing products with AI features baked in, All the way down to testing the models themselves. So in this episode, you're gonna learn where AI assistant quality starts producing diminishing returns, why a fully autonomous test generation pipeline can create more work than it saves, and how Swati broke hers into 2 steps and got reliability back, and what she will and will not delegate to an AI, and the 2 competencies she says every tester needs to survive in the next 5 years. Stick around, you don't want to miss it. Check it out. Hey, before we get into it, everything Swathi is describing here, whether you can trust what AI hands back, whether your team even has the skill to judge it, is exactly what I'm trying to measure right now with our TestGuild State of Automation Survey 2027. It takes a few minutes, it's completely anonymous, and the results go into the report that drops in January. So if you want your voice heard and your team's reality reflected in this data instead of someone else's, head on over to that link. Down below. Look forward to seeing your survey results. Hey, Swati, welcome to the Guild.

Hey, Joe.

Good to see you. I've heard a lot of great stuff about you, uh, from former Guild members. And, uh, one of them was, I think you did a session at CAST, I think earlier this year. Actually, it was earlier this month, so it was actually pretty recent. Yeah, nice.

And it was on, uh, the, um, it was on the old thread, new name. Do testers need to be worried about AI?

Yes, yes, yes. Which I think is on top of mind for a lot of testers right now. So, you know, the session says the old threat has a new name, but automation, you know, all my life I've been told automation is going to replace us, agile, DevOps, now AI. Why does the same story keep coming back over and over again from people?

That's a great question. And I think, For some reason, I mean, just to give a little bit of a background on where I come from, I come from a strong computer science engineering background, and I've gone through 4 years of computer science engineering, and there wasn't a single subject called software testing. So, that kind of lays the foundation of the thinking that testing is somehow, as an independent discipline, is not valuable. But then the reality is that when we build these software products and ship them out, we find that testing is an inevitable part of the entire process. So, sometimes I feel like we are forced to have these testing teams, but there's always this narrative that if automation becomes more mainstream, or if infrastructure becomes cheaper, or if AI gets into the picture, somehow we can eliminate that, going back to the the myth that software engineering as a discipline did, where we only focus on development and not so much as testing. Testing is somehow, I think it has that identity crisis from the start, and that's been perpetuated throughout history, and we are still at the same place.

Absolutely. Do you think AI is the opportunity though, where the testers strike back almost? Because The, the 100% AI is generating the code.

Yeah.

And now the more important piece is with all this code, we have to test it. So where do you see the role of testers now? Do you see, um, like the, the roles of developers and testing morphing, or do you still see testers as a distinct career that people will still have in the coming years?

So the development and testing morphing, or those disciplines working hand in hand, or, you know, that cross-training is always valuable, Joe. I really think as testers, when you— we can read the code, the closer to code or the source code of the application that we are, the more knowledgeable we are about what exactly is going on. Because, you know, I find that when you report a bug, that may or may not get the right attention that it deserves. But if you do some work and figure out where exactly it's coming from, 100%, it gets fixed. And with AI, right? I mean, sure, with AI, will testers become developers? Maybe, may not be. And what I find in my experiments becoming easier is for the tester to become the developer. Like, if I'm trying to teach my Copilot a new skill, I don't have to know how to write a PowerShell script. I can have the AI do it for me. while I go through it with a fine-tooth comb and figure out whether it's doing the right thing or not. And I know how to test already, so I'm going to be testing it as extensively as I possibly can. So developers and testers intermingling is not a new concept, and I find great value in that. But with AI, will testers become developers? In fact, even developers don't have to be like developers, developers, right? Because now you have all these generation assistance that you can get from the AI tools. So basically what the evaluation part of that AI output is at the forefront, I think, on all of our minds because generation is now cheap, but making sure the generated content is usable, whether that is actually valuable, That will that become an asset or become a liability? Those are the questions that we are trying to answer. And testers are uniquely positioned because we are already thinking about all of those things already, because that's some of the core principles, right? What evidence do we have that something's valuable? What evidence do we have that will support our judgment? So these are some of the things that will become a common capability irrespective of what your role is, as long as you're working with AI output.

Gotcha. So, it's kind of funny getting older. When I started, you know, it really was about testing, being business domain experts, and then knowing about risk and evidence. And then it became like, oh no, we're developers, we're first-class developers now. We need to know how to code and know algorithms. And when you go for a, like a job interview, you're getting these developer interviews, and it wasn't about testing. Now, it seems like it's swinging back to, you know, we have to be business domain experts, know about risk and evidence. Well, we should have always been. I don't know. Any thoughts on that?

Absolutely. I think, you know, even with AI, especially with AI, without the right context, AI is just going to give you answers that look intelligent and confident, but may not actually be usable at all. Right? So, that intelligence is, we can call it business domain expertise, we can call it context, we can call it, you know, retrieval support, we can call it what we want. But at the end of the day, the more we know about the system, the more we know about our customers, that's how you distill that knowledge and information and provide that as an input to AI. Right now, that's what we are thinking about, but that core fundamental of that customer focus, and business outcome-focused. That, I don't think that'll ever change.

Yeah, and to me, AI is very seductive. It almost like—

It is.

Kind of makes you think, oh my gosh, it's so smart. And then you look at it like, what is this? So in your abstract, something that popped out to me, I guess along those lines, I'm just curious to know what you meant by it, was about AI, the AI agreement is not evidence. So, like, when teams mistake agreements for evidence, what does that mean? What does that look like?

So, a lot of times, we are using AI to test our theories and to have our prejudices confirmed, right? And AI is very, very sycophantic when we— I mean, that is, I think anybody who's used AI for any amount of time can go ahead and say that because When you say, let's say I have a test strategy in mind, and when I input that into, let's say, a Jira Rovo or any other AI assistant software that you might be using, and say, for this requirement, this is my test strategy, 99% of the time AI comes back and says, this looks great. And that's how it starts. And that can give us a false sense of confidence. correctness and false sense that, you know, and the more verbose the outcome is, we tend to focus on what it says in the first few lines. And the first few lines are almost always agreeing to you. Is that your experience?

Yeah, yeah. Now that I'm thinking about it, it's so true. Like, just for fun, I vibe-coded a bunch of applications on my website and just to learn it. And you're exactly right. I never thought about it before, but it does start off like, Hey, great job, blah, blah, blah. It's not like, you know, whoa, risk, risk alert, you know?

And it always— sometimes you could also get in a kind of loop with AI, right? Because the context windows keeps growing. I find this especially true when I'm trying to write an automation test that just does more than what I'm asking it to do. So I'm asking it to like think edge cases or something that I haven't thought thought about. So, if I do this 100 times, let's just say for the sake of an example, each time it's going to want to end with something that it suggests, right? It's always not true, but that's the algorithm. It's trying to— it's like a sandwich. It tells you what's great about what you're already doing, which may or may not be great to begin with. Then, it just gives you a bunch of assessment, and then it says, this is the one tweak you could do. And then, if you have the agentic mode, sometimes actually goes ahead and does it, and then you are left with the job of going through the whole thing and keeping versus undoing. So, there is a point when the AI involvement starts having diminishing results. But, you know, which is why I really think, for us testers, especially when you're using AI assistants, to do it the right way, to understand AI at a You know, a little bit more intuitively than, you know, there is no— you only gain this by engaging with it more and more. So, not giving it enough context, trusting it from the get-go is a risk, but also engaging with it so much that it puts you in an infinite loop, that's a danger to watch out for too.

Yeah. So, like I said, It's hard. It's self-controlled because it says, would you like me to go blah, blah, blah? And you're like, yes. And you're like, I want to press Enter so bad, but you could keep doing that all day. That's so true. And it just eats up tokens and tokens doing that.

Exactly.

So is this a failure mode kind of like when you see a green dashboard, but the tests really aren't doing anything? You're just going, oh, it's green. You never really looked at what the tests are. The tests are like, 5 years old, they may not be doing it anymore. Is this like the same kind of problem where AI sounds convincing, but like you said, is it really doing what it says it's doing?

Exactly. So, if we don't know the— okay, I'll tell you. This is an example I've used in CAST too. And my son and I, my son's 15, he started high school last year. So, during the summer, we were just daydreaming and said, okay, let's ask ChatGPT to play the fortune teller and tell us what you'll be doing when you are 21. So, that's exactly the question we asked it. So, what would my son do, 15-year-old son do when he's 21? And AI comes back and says, in 2047, Nikhil's going to be doing so and so. So, what it essentially did was added 21 to the current year. In 2047, my son will be 36. So this is a simple arithmetic error, and we would— I would catch it, my son would catch it because we know his age. But if this were to be a question about something a little more complex, right, if it was in the context of, let's say, a manufacturing problem or something to do with an algorithm that's complex to begin with, it is very hard to be discerning in that case. to understand what exactly— see, because also AI generates an answer fast. Sometimes it compromises on completeness and makes that trade-off of being faster. So it's fast, it's confident. So sometimes that speed with confidence can be misleading, and it might make us feel like it's doing the right thing, and it's very easy to accept that. AI output unless you, like we talked about, are the business expert. You really have to be. And all these assistant tools are called assistants and copilots. I believe that's because you are still the main person. You're still the pilot in the equation.

That's a great point. I was talking to someone on the podcast about, they were doing something with space. They were working with NASA and it was feeding on these documents and then It was saying, you know, when this hits this gravitational pull and, you know, the, the, the, you know, the, the weather and all that type of— it was some crazy equation. And he's like, I don't know if this is right. But then he's like, oh, we just create an agent to verify it. But I'm like, doesn't that kind of like— how do you know that the agent is right then that's verifying it?

Yeah, I do that sometimes too because, um, I work in the semiconductors industry, lots of physics involved.

Yeah.

So I do, I use AI to help me walk through a certain physics-related situation, but I let it teach me in chunks that are small enough for me to process and fully process before I am ready to absorb the next chunk of information. So learning that way has been super easy for me. In fact, I've learned a lot about the neural networks and all the math that's involved in AI algorithm generation. Through AI. That's as meta as it can get. But at the end of the day, you have to be the one in control. You have to be the one who asks the pertinent questions and make sure that you understand it completely, fact-check. But again, I think the thing that works there is to break that big chunk of a task into smaller understandable things and guide AI, provided the input at each step that you are okay to move on to the next one.

How do you know you're okay to move on to the next one, though? Like, what's the evidence that you would look for that's okay? Right.

So, yeah, in my case, at least, if I was breaking my physics problem into smaller chunks, I kind of know what the end result is. I kind of know, you know, what the workings of, you know, the machines that we are testing is going to be like. So, I'm going to have to, like, pair up my real-world knowledge to what it's telling me. to make sure that that computes. So you have to have a frame of reference. So if you were learning the math, then you need probably— you probably need a textbook and then it can make that understanding of the concept itself easy. But, you know, it's, it's not something that will— you will have to fact-check it for sure. Love it.

Once again, I'm just going back to you. I didn't see the session. I'm going back to the abstract, something about things that could be delegated. So, what would you be comfortable with delegating to an AI, knowing all that you know and what you just told us?

That's a great question. And I was asking this question myself, right? I mean, the other day, like I was saying, I experiment a lot with teaching GitHub Copilot with a lot of assistants. skills, because everybody's got a lot of tech debt when it comes to test automation and test generation, keeping the tests maintained, things like that. So, I initially started with this idea of, like I said, I work very closely with the source code, and we have a lot of source code that's already in production that does not have a good test base. And that was what I was trying to tackle. So, my idea was I was going to create an MCP tool where I was going to have— I was going to provide a particular functionality, have GitHub Copilot go through the source code and give me all the test scenarios, positive and negatives, that can be tested. So kind of like a coverage analysis. And I provided it the template that I wanted it to follow. I understand there's all kinds of loopholes in this logic because if you're testing from the source code, you may not actually catch you know, the problems and all kinds of ideological differences. But I know that once it generates me that raw list of test cases, I'll be able to parse through them and decide which ones are right and which ones are wrong. So my idea was to do the test generation, have it output a CSV, and connect my GitHub Copilot to the Azure DevOps where we keep our test cases. So it would generate it, upload it, and we would have it all in one place. This would have been a total delegation of the task beginning to end. At the end of it, we would have test cases in Azure DevOps, which meant we tackled the problem of the technical debt completely. However, what I did was I broke that task into 2 pieces. I broke that task into just generating the test for me, which is just the CSV files, and then the MCP tool, the upload process itself. Itself was a separate process. So if you see, I am delegating test generation to a certain extent and the uploading to Azure DevOps also. So there's delegation on those 2 ends of this one task, but I decided by breaking it up and not making it fully autonomous, I'm compromising a little bit of a speed for accuracy. So I'm the middle person here. When I have the CSV file, I I make sure that I go through these scenarios, vet them out for what is too basic. Like, some things are too basic, and we don't need to document all of that. Testers know how to do these things. So what is too basic versus what is required, what are the duplicates, all of this good stuff that we do during our review process. So there is a lot of delegation that can be done, but again, we have to use our judgment on where we need to come in. So, the delegation works smoothly, and the output that we generate does not create more work for us, and it actually serves the purpose that we intended it to do.

Absolutely. Just random thought came to my mind is that, you know, we're being told that AI is gonna replace us, but you just gave an example of you're creating an MCP server.

Yeah.

When would you ever have had time to do that before?

Exactly.

And like, what— And what skill, like, I mean, that's not a skill you just were born with, right? You had to probably learn that. So, you're doing more, it sounds like.

I have spent hours poring over code on Stack Overflow and whatnot. Yeah, yeah. It makes experimentation so easy, AI. So, it's not something we can really sneeze at. It's really helpful, but when used right, with the right amount of judgment. So, AI literacy is really important. But so is testing depth. So, it's both of those, you know, 2 competencies that have to go hand in hand. And one of the things in the talk too, it started as automation replacing testers, but it's not going to do so. That was the initial premise of the talk. But as I was developing it, I figured out that we lump a lot of things into this generic term called AI testing. And AI testing, I feel like, is too broad a word to encompass everything that is part of AI testing. And I come from a teaching background too. So I always think about how would a beginner interpret it? Like, when we throw the word called AI testing at somebody who is a beginner tester, how would they interpret it? What would they need to learn in order to you know, tackle this whole new thing. Same thing with automation testing. We call a lot of things automation testing, but that field has been mature enough to say there is APIs that we test, there's visual testing, there is, you know, UI-based testing, performance testing, accessibility. All of these can be automated, but they have different disciplines. So same thing with AI testing. I feel like AI testing itself is a big word, but there's a lot of things within it. The first thing is you could use AI for assistance, right? All the things that we've been discussing, whether it's using Copilots, whether it's using MCP servers, setting up your right context, so on and so forth. Even if you use ChatGPT to just, you know, go back and forth on some testing ideas, that is still AI assistance, right? At the core of all these AI assistants, AI will generate some outputs. You will still have to put on your evaluation hat and decide what we keep versus what we discard. And then to do that, you need to know what needs to be trusted versus what cannot be trusted. So all of this cannot be just left on human interpretation because 2 people, even 2 people don't judge the same AI output the same way. So we need these coding evaluation rubrics, evaluation datasets, a very strong framework to both evaluate the evidence and also the output. So one part of AI testing, I believe, is AI assistance, but the next is the AI evaluation and trust. That, I will say, is the second one. And the third one is when we have all this AI output, right? There's several inputs that are going into it as well. We are using prompt files. We are using these, like I was telling you, the MCP tool. All of this is software, additional artifacts that we have to find a way to version, that we have to find a way to make sure that their quality is being maintained. There's a lot of processes that have to be in place. So who needs to be responsible? Who needs to be accountable? Who needs to be informed? The RACI framework, all of that. So the third part of the AI testing can be your governance and making sure that the AI development itself, the whole process itself, is sound, right? And that's a core part of the QA processes also. We don't just test, we also establish these processes that will help us gauge the software maturity lifecycle itself. So the third area of AI testing could be a little less technical but not any less important, which is the AI development quality work. And then finally, we could categorize this as one, but I like to call it as 2 different things, which is testing the products that contain AI functionality. Right. So the traditional QA practices don't hold here because we are not just testing for a particular value becoming a certain way or the other. Right. The traditional assertions don't work anymore. So because we are going from a deterministic to a probabilistic system, so we need a different evaluation set. So our automation frameworks have to evolve. I have to evolve from being that, you know, 0-1 Boolean-based validations to we have to validate whether the answers are correct, whether we are getting them in the right time. There's a certain amount of repetition that we have to bake into our automation frameworks because you can get a different answer from AI every time you ask the same question. So the automation framework has to repeat the question a certain number of times so you can understand the nuance of that answer. Right? And a lower level of testing AI products with AI functionality is to test the model itself, because a lot of teams I know are moving from getting the third-party LLMs to having LLMs that are in-house. They're building their own systems, they're building their own, training their own models, fine-tuning. We don't have to be AI model engineers. as testers, but there's a certain amount of gray box treatment that we have to provide to the model itself. So, we think about things like observability. I was, as an experiment, building a RAG-based AI LLM the other day, and I had it do just one thing. I gave it a PDF from the OSU Master Gardeners watering guide, like, when do you water your plants? I just had it retrieve the answer from just that one 2-pager PDF. And I asked it the question, when do I water my tomatoes? And guess what? It comes back and says, when the soil feels moist. And that is obviously incorrect. You wouldn't water a plant when it's already moist. But the question for me was, how did it get that wrong answer? Because I I clearly trained the model to get it, get the information just from the PDF. So I had to integrate the LangSmith framework so I could take a look at how it was processing my input and eventually generating that output. So observability becomes an important thing. So these 5 areas like AI-assisted testing, AI evaluation and trust, AI development quality, the AI testing products that contain AI functionality, and testing the AI models itself. So AI testing, in my opinion, encompasses all of these 5 things, and each of these have a different test intent and a different technique, different tools. So if someone's interested in learning AI testing, these are kind of like the broad areas in which they could focus on, because I didn't want to just leave the talk with Okay, automation did not replace testers, so AI will not replace testers. I wanted something actionable from that talk, and I believe this helped me frame me in how I approach learning about testing and QA in AI. I hope it helps those who listen to this as well.

Yeah, great framework. You know, we started off saying you went, you have a degree in computer engineering. You didn't have one course on testing. And now you just laid out 5 areas of testing AI that is cutting edge. Like, how do we learn that then? It's like stack on top of stacking.

And it's not like a maturity model. So it's not like you start with AI assistance and then you, it's not like that. So I would say just start using AI. That's the first step. Step in anything because the beauty, like we were just talking about it, the beauty of experimentation these days is that's cheap and quick. You can try something out in probably like an hour and decide whether that's working versus not working because all you need to do is now define what you want in like natural language, right? Even if you don't go that far, you should just start using AI, even if it's something like composing an email. You could, I mean, we all can write emails, but make AI write some emails for you. And then intuitively understanding at what frequency does it hallucinate? How is the AI outcome? So, one thing I find is AI outcome is very, very verbose, and I don't like that. So, I constantly tell it, tell me in like 2 lines, 2 words, what is this? So, engaging, the more we engage with AI, the better it is. And I think most organizations are already adopting things. So, we have— most teams I know have GitHub Copilot if they are automation engineers of any kind. And I know Jira Rovo is very popular. So, engage with those tools. I also think the testing fraternity itself, we are a little— how do I say it? We tend to hold on to certain beliefs, like we always find people who are team exploratory testing versus team automation testing only, or team certifications versus team non-certifications. I feel like that kind of divide in AI could be hurtful. Just experiment with it. I know that a lot of people think it's intellectually weaker to engage with AI, but that could be very hurtful because AI can accelerate a lot of learning, a lot of work really fast. So, back to your question of how do we develop this competency? Like I said, AI is ubiquitous nowadays. Engage with it as much as possible, and then start thinking like testers, right? I mean, whenever AI produces an output, whether it is in real-life situations or work situations, challenge it. And when you're challenging it, try to be discerning about what questions are you asking within yourself. Be a little more transparent about that process. Be a little more— I think if we spend some time thinking about why do I think this answer is correct. Like, even if it's not a straightforward arithmetic error, if I feel like something's off, um, what is it that's off? Let's try to like put a word to it. Let's try to define it. What is it that we don't like? Um, is it the tone that we don't like? Is it, um, the length of the answer that we don't like? So this is how we develop a very strong evaluation mechanism within ourselves. It doesn't have to be for technical output, for any general AI output. When we start challenging it, then we know what becomes trustworthy versus what doesn't. Well, again, like I said, experiment with it. So with a chatbot, and a lot of times the question that I get is, can any of this evidence, right? Because it's, it's a lot of nuance. It's about how I feel in this situation when I get an AI answer. Do I like it versus Do I not like it? How do we tangibly define those parameters? That's one of the questions I get a lot. So every time I get a question like this, what I try to do is I try to quantify that in a way that becomes a repeatable framework. So on my GitHub, there's a lot of Python projects where I have like created small chatbots with OpenAI and then use another agent where I test And I try to use different LLMs versus same LLMs conducting the different experiments. But what I found is if you are trying to evaluate for correctness, you could always provide it some criteria. Again, just to say, just to kind of underline my core belief, it's that AI is prone to hallucination, but it hallucinates more when it has less context. When your context is great, whether it's in the format of your prompts or whatever is your evaluation criteria, when its context is better, the chances of hallucination are lower. And like I said, when you use AI a lot, you kind of understand its nuances. I have a test generator tool in my MCP, not the manual testing one. I have one for automation tests. So there's a bunch of things that I wanted to do. I'd like it to write the automation test. I'd like to also catalog it in a CSV file so it gets eventually picked up for running on the CI/CD pipelines, right? But inevitably what I find is it creates the test but always misses out on putting that parameter, cataloging it in that CSV file. And I've asked it repeatedly, repeatedly, and it's part of the test instructions. Markdown file. So what I'm understanding is, without not a lot of visibility into the model itself, what I understand is that it compromises on completeness for speed. So it's making that trade-off. It's trying to give me an answer, do the work that I'm asking it to do in a certain amount of time, which I think— I don't know who's deciding that, But it's saying, I need to be fast, so I need to respond within this time. So it kind of like misses out on a few activities. So a better option in that case would be to break that workflow into 2 separate events and have the test generation separately and have the catalog option separately. So I mean, it's one additional step for you, but you would get more reliability. So all of these AI-related evaluations can be automated. And I have some examples on my GitHub that I'm happy to link after, where we provide examples of what are correct answers, what is the correct tone. If for some reason AI does not know an answer, we force it to say, I don't know, or provide more information instead of hallucinating and giving us a completely incorrect answer. So to learn AI product testing and testing AI models, that is a little bit more technically intensive process, but completely within the reach of pretty much most of us testers because it's not technically complex. And all the complexities can be made to be handled by these AI assistants, but there is a certain nuance to learning to work with them also. So, the more you engage with it, the more comfortable it gets.

Absolutely. Is there anything you wouldn't trust AI with for testing?

I would or wouldn't?

Would not.

I would not trust it with— I would not trust it with pretty much anything without me laying eyes on it. I would let it do the legwork for me, but I wouldn't accept. Anything as absolute truth.

Love it. All right, some quick, quick answers, lightning round. Should a tester, say, with 10 years of experience be scared right now?

Only if you are not keeping in— only if you're not keeping up with the progress that the world is making in terms of technically. I want to take 1 minute to answer that question a little more. In more detail, Joe. I really think testing fundamentals are great, but you have to also have the chops to do the actual work on the day-to-day basis. So if you— if we only know the one type of testing with a record and playback kind of mechanism, that's not going to cut it for the fast-paced open-source library-based test automation that we're doing today. So it doesn't matter how many years of experience you have. The business domain is only applicable when you are in that business. But the other skills like automation, you know, being more comfortable with the modern tools, modern frameworks, using AI, these are things that are applicable across the industry. So if you're not updating yourself, yes, you have to be worried about. And that's not because of AI, that's just in general.

All right, Swathi, before we go, is there one piece of actionable advice you can give to someone to help them with their AI testing learnings right off the bat? And what's the best way to find or contact you?

The best way to find me is on LinkedIn, Swathi Seela. Same email, swathiseela@gmail.com. I'm always available. I have my GitHub, Like, I think we've already touched on this, but 2 things are absolutely essential for QAs to continue and thrive, which is testing fundamentals. There's no replacement for that. You know, that's the foundation on which everything else gets built on. And AI literacy. Don't hate it, don't love it, just use it. It's a tool. It's there to help you only if you know how to use it.

And you can find links to all this awesomeness down below. Thanks again for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com/a602. 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, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real-world challenges, we're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences Together, let's push the boundaries of what we can achieve. Oh, the Teskel Automation Testing Podcast! With lutes and lyres, the bards began their song—a tune of knowledge, a melody of code. Through the air, it spread like wildfire through the land, guiding testers. Showing the secrets to behold.