Overcoming Mobile Testing DevOps Challenge (Episode 3 of the SmartBeat Employees - Mobile Testing) with Todd McNeal

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, today we're talking all about mobile testing in DevOps with Todd, you don't know. Todd is the co founder of Reflect, a test automation tool that can execute manual test cases using AI, which was acquired by SmartBear, I believe in 2024. Todd, if you don't know from previous episodes, is really passionate about making test automation easy to create and maintain. Every time I talk to him, there's something new development going on in AI and testing. So really excited to have him back on the show. You don't want to miss it. Check it out. Hey, before we get into it, this episode is brought to you by Smart Bears Reflect, the no code test automation platform that lets you build and run end to end tests right in your browser. Fastest setup, easy to scale. And now with native mobile testing, spend less time fixing flaky test in your DevOps pipelines and more time shipping quality software. And try it out for yourself using the special link down below. Hey Todd, welcome back to the Guild.

Thanks for having me, Joe.

Great to have you. So every time, like I said, every time I talk to, there's something new going on in AI. I'm already off topic, but the latest I've been hearing about is MCP and I guess maybe we can add it to mobile testing. What is MCP and does it? Can you see it helping automation for mobile testing down the line?

Yeah, there's a lot of chatter about that and a lot of recent activity on it. MCP is a protocol for allowing LLMs to basically communicate with things like web browsers. And so I think where I would apply to mobile testing is giving the LLM the ability to perform actions or get data on a mobile device. I think, yeah, definitely relevant to mobile testing.

All right, so last time we were on when we talked about Reflect, I'm just curious to know, did it support mobile or is this something new?

This is new. So we, the support we had for mobile was for websites that are running as in a mobile browser, but we never had support for native mobile apps. So that's. This is a totally new feature for us now.

Once again, I could be wrong. When I was doing testing, people always talked about mobile testing, but we never really did it. Were customers clamoring for mobile testing or is this something you saw as a need?

Yeah, we've heard that consistently from customers about wanting to have the ability to do low code and no code testing with mobile. There's certainly existing solutions for that. But a lot of the customers that we've talked to, a lot of customers that reflect they're still doing it either mostly manually or almost exclusively manually. So that could be either. You know, pretty much every tester who's doing mobile has a phone in their pocket or in a drawer somewhere where they're testing. But then that also might be through like a grid, a mobile grid or in some cases would have the mobile grid within your own data center. But yeah, a lot of folks from our surveys and talking to customers are still doing it almost exclusively manually today.

Yeah, so that's a good point. I guess a lot of mobile solutions aren't necessarily low code, no code. So is this a different approach that you've seen from maybe what others are doing out there?

I would say the approach will feel similar to other low code, no code solutions, but the implementation is different. So the way I would describe mobile testing automation is if you're a developer who's doing testing, say you're a product developer, mobile developer, your tests are probably going to be using one of the native frameworks like XUI Test or Espresso. That seems to be a favorite of developers. And you're probably running those tests on emulators because they're cheap and fast and you can run them for every change that you make. And then for test teams, quality engineers, they would typically be using something like Appium. They may be using XCUI or Espresso, but Appium still has a lot of market share and they would be running on physical devices. From what we've heard from testers is that they almost exclusively prefer running on physical devices, either in their hand or on a mobile grid, because that's the way that they can best replicate the end user experience. There's always these, if you talk to mobile testers, there's always these weird bugs that you see in an emulator but not in a physical device and vice versa. So they want to try to avoid those. But with the low code, no code tools, it's a lot of what you see on the web, it's the record and play experience. And you know, it's, it's using Appium under the covers, but it's record and play. You're clicking around and it captures your actions. That approach is similar to what we're doing, but we're using a pure AI approach to it that has, we think, some pretty significant advantages.

So you mentioned using a pure AI approach. Can we dive in a little bit more? Like, what do you mean by that? How does it help? Maybe the experience be a little bit different than people might be used to, or what the benefits are of using more of a pure AI approach?

Yeah, so there's some pretty cool benefits to using a pure AI approach. So, number one, with the workflow, like a Record and Play workflow, we know that a lot of users prefer Record and Play just because it's easy to get started. You sort of know exactly what it's going to do within the app, you know where you clicked on, and it's very similar to just interacting with the app directly. What we're doing with Record and Play is making it totally AI. And so what that means is that when you tap on something, we're using computer vision to generate a prompt, just like you would use a prompt in ChatGPT. And we guarantee that that prompt will replicate the action that you just took. So whereas with typical Record and Play, you're going to generate selectors or locators, which tend to be flaky, as the app changes, it needs to use the implementation of the app to find that element. And so if you change something about the app or the data changes, it could break. We take a computer vision approach. So we're interacting with basically a screenshot of the mobile device at the point at which you tapped on something and we use that to generate a prompt. So it's a really cool way to provide that same user experience to the user that's really easy to learn, but gives a lot more in terms of maintainability.

Okay, interesting. So does this also make it like a lot of times you have to have a test suite for Apple and Nila test suite for your Android, because you're using Image base, does that mean you can use this one script and run it on all the places on mobile, then?

Yeah. That's another major improvement over the current state of the art, is that when you look at app development, at least recently, a lot of app development teams are using things like React Native or Flutter, which is where you're using web technologies, so it's easier for web developers use it, but it also lets you have one code base for your app to deploy on iOS and Android. So the problem with that, there's a couple problems that it creates for the tester, but one of the big ones is just what you described, which Is that if you're using, even though you have one code base for building the app, you tend to have two separate tests for iOS and Android, even though functionally the same, just because of limitations of the testing tools. So what this allows you. Because we're completely black box, we're never using the internals. You can actually create a single Test suite across iOS and Android.

All right, how about screen resolutions now? Because once again, it's image based. Does it make it so you don't have to worry so much about the exact resolution of the screen you're running against?

I guess yes. So our solution for that is when the each step runs, so we talked about with Record and Play, it'll generate the prompt and then we will run the prompts. That's using our existing AI and Reflect, where if you, you know, typed out a test step or you imported your test from a test case management tool, it uses natural language processing to figure out where to tap. That always runs at runtime. So that's how we can give you the ability to run that same step set of steps across devices. Because if in the tablet version that button is bigger and it's over to the left, the AI is at running at runtime, so it'll find it versus if it's on your mobile phone version and it's at the bottom, it'll find it for that version because the AI ran at runtime to find it there.

So can you explain a little bit more for people that maybe haven't used Reflect before? So natural language, do you just say, hey, log me into the application and enter a patient by just saying that high level. All the details of how to do that is handled by the tooling. How does that all work?

I guess so the way it works is you give instructions step by step instructions to reflect and the Reflect AI will run it. The best way that I use to think of it is think of it as a manual tester within your organization that just started. So they don't really have a lot of information about how your app works. Maybe they don't have the knowledge about your industry or something like that, but they can take step by step instructions, even if it's their first day, and be able to replicate it if those instructions are detailed enough. So the detail that you would ideally want to use for the Reflect AI is tap on this, input this and this form, validate that it shows X. You could ask it a question like is there a subtotal displayed on this page? And it could give you a yes or no, so it's that sort of level of detail. It's not quite the go in and place an order on the Amazon app. It's more of that level of detail.

Gotcha. So if someone says click on then and it changes, say it changes. Like you have all these, these tests and it says click, click, click, click, and it turns into maybe an enter or a tab or something. How do you work around that? Or is that even an issue?

Yeah, so that could be an issue where I can see that for if an additional form field is added, something like that. I think in that case, if you added a form field that was required, the test would fail. And so you would need to update your test because the requirements have changed. Right. Like if you had a. A test script that said enter these form fields and then a new form field was added, it would fail at that point. So you would see the test fail immediately at that point. Where the resilience comes in, where the AI runtime running at runtime comes in, is as things change, either something changed internally and you can't see a change, but something under the covers change that would cause the selectors to fail or something visual change, like, even like a full refresh. So a good example there might be. Let's say you're testing a login workflow for your app and maybe you're AB testing certain things and the login button is green on one and red on the other. In terms of. If you think of a manual test case, it doesn't matter. It probably just says something like, click on the login button. And you would never consider red or green to be a defect. Right. The tester is able to figure it out. Those are the kinds of changes that the AI will just pick up naturally and never flag it as a false failure.

But does it flag it? Like, everyone's like, oh, I don't know what happened. It said it passed, but does it. Like in the report, does it say, okay, it passed, but the color change, like, does it give you that type of detail without you telling it? Does it bubble up that insight?

I guess the question, that's a great question. If your test that was saying, just tap on the login button, it will perform that action. So it would be as if you gave it to a tester and the tester didn't know what the login button looked like in the previous run.

Gotcha.

Yep. You know, they're just looking functionally at that. We do have a capability called visual testing which would let you check for those kinds of Things, but that's, that's sort of a thing you have to explicitly add to your tests.

Gotcha. Sorry. I know with mobile testing a lot of times people don't think about performance or ux, so I know a lot of changes happen in the industry in the past few years. So do you have any strategies then that you're baking in to help people not only just with functional mobile app testing, but also maybe performance and ux, like you didn't mention visual testing really quick, but did you do anything with performance as well?

So where performance could come in is when you're testing an app. It depends on the test team. But some test teams really have an emphasis on verifying that their app works in poor networking conditions or testing on phones that are older. Right. So they have less CPU or something like that. So with our mobile app testing solution, we provide you with mobile grid so you can choose from a set of physical devices. Some are older, some are newer and then you could also connect it to your existing grid if you wanted to. So like a browser stack or sauce labs and those depending on what plan you're using and what provider you're using, those tools might have things are ready for you to say for this particular run, I want to set the network speed to this, like throttle it or I want to run it on like a much older phone. Some teams even have their own dedicated phones because they want specific versions of phones to test on and so we support that as well. So I would say that's probably the biggest use case I see for networking performance that I think we have a pretty good solution for that.

So nowadays when you talk to customers, does anyone still have an in house mobile farm? And why, I mean, sounds like it'd be a nightmare to maintain.

They do. It's, it's. So we did some surveys on this. One thing that's interesting is pretty much every mobile tester that we surveyed has a phone in their pocket that they're testing. So if you had asked a tester, mobile tester, do you do local testing? Do you testing on physical devices in your, in your hand? 100% would probably say yes, that's what we saw. So what it seems to be the case is that that is something that a tester maybe only does that as a quick smoke test or something like that. They just want to have the comfort that it's working on an actual device before it goes ship, shipped, live. But there actually are teams that prefer to have their mobile testing in house. So that would be, it would tend to be industries that are regulated industries. So it would be like government, healthcare, but some finance would be things like that where they just don't want to even connect it to the cloud. Those are also the areas where we tend to see those customers wanting to have on Prem solutions versus cloud solutions for other kinds of things as well. So yeah.

So does Reflect work on Prem as well then with your own?

Yeah, Reflect does not. So Smart bearer's tool, TestComplete does. So that's where with our mobile solution we're focused on the folks that are comfortable running within the cloud and then for folks that are using that are on prem, they want to stay on prem. Test Complete would be the solution for them. And that's been kind of a trusted name for, for quite a while in testing.

So TestComplete has been around for a while. So Reflect doesn't replace TestComplete for people that may be just getting up to speed here. If they have a desktop application or some other things Reflect doesn't handle, I guess they would choose one over the other or do they work together eventually?

Yeah, exactly. So you would choose TestComplete for the use cases where you're doing maybe primarily desktop testing or you want to focus, you have a strict focus on on premise due to security or regulatory requirements. And then Reflect is the AI native tool, the cloud based tool where you're a cloud native company, you want to use the latest and greatest AI tools and you're comfortable running those tests in the cloud within a cloud solution.

You may have mentioned this, I may have missed it. Now this does work on real devices. Does it also work on emulators or do you just avoid emulators completely?

We focus specifically on real devices. Yeah. So what we've heard from customers and doing surveys and market analysis is that the folks who tend to want emulators tend to be more developers. So the actual folks who are developing the mobile apps, whereas the test teams, the quality teams, are typically looking for physical devices. And so we're really focused on the quality teams and the test teams with this product. And then, you know, because that's really where the bulk of your testing is going to occur anyway. The developer teams tend to want to have a small core set of tests that run frequently. And then the test teams would have that really large robust complete set and they're looking to automate whatever they can there, but would also be doing some manual testing too. So we're focused on that use case. Nice.

So where else can AI help with mobile testing? You didn't mention it's able to self fix itself while at runtime. Are there any other benefits of using AI that are in there now or maybe you see down the road?

Yeah, so one general benefit, and we see this on the Reflect website, is being able to use natural language prompts. So actually typing out your instructions to get the level of detail you want for a particular test. So the example I like to give there is if you imagine something like within a mobile context, a lot of times there's lists of things and you're scrolling through that list and trying to find it. A lot of times what you encounter with testing is that you want to find an element within that list. Tap on. But how do you find it if it's a record and play, typically record and play is going to be using it either based on the name that you give or its position within the list. And you don't really have control over which way it finds it. But with a prompt, you can get really creative and really specific about how to find that element. When the list, you could say something like tap on the element in the list. That's the second item in the list. So that's always the second item. Tap on the element in the list that says Joe Colantonio. So it'll scroll through the list to find it. Or it might be something that's even more complex, like tap on the item in the list that has a quantity value greater than a thousand. And so that's one area where it actually might make sense to write out your test up explicitly just so you can be extra sure. It's always going to work regardless of how that test data looks in the future.

So are there any prompt best practices then? Could someone write a crummy prompt and then we get crummy results?

Yeah, unfortunately you can write crummy prompts to get crummy results. It's sort of the, the old adage of garbage in, garbage out.

Yes. Right.

And so I think, you know, maybe eventually it'll become impossible as AI just gets better and better and better. But it is, it does take a little bit of skill today. I think prompt engineering is definitely a skill you require. Some of the things that I like, I like to suggest are using quotations around things that are specific. So if you're looking for an element that says Joe Colantonio, I would actually put quotes around Joe Colantonio, which is a nice hint to the AI to look for that specifically and then just be as specific as, as you can, but not more specific. So sometimes you have a tendency to, you might have a tendency, especially folks new to AI, since it's new to a lot of people, to want to be super, super specific. But that's almost like you're introducing these super, super specific selectors. So you, you don't want to say something like tap on Joe and Colantonio, that's right in the middle of the page and it has this element next to it and it's blue or whatever because if those change, then your test breaks. So sometimes you actually want to be a little more general when it requires, just so that your tests don't break needlessly.

Yeah, that's interesting because some people say the more you need to be as specific as possible with LLMs because they'll hallucinate with the more and more context you give it. So it sounds like not necessarily the case in this type of domain of testing mobile apps.

Yeah, some customers have come to us and I, I get to talk to a lot of customers and they do think that the more the better. And it's not always the case. You know, sometimes even people will try to be, try to give the AI hints like saying, here's the selector that you should use or something like that. And.

Oh, right, right.

Yeah. And it's really, it's really meant to look more like how you would describe it to a person. It's really meant to be like if I, if we were working together and I said, hey Joe, can you test this test case for me? And you said, sure, what would you like me to do? And it's really just kind of give you the step by step instructions for that. That's how to, how to think about it.

And I guess that's even better. I guess the report would have the step by step instructions so you can almost act like, did this test really do what it did? So you can just spot check it because you're able to follow along. There's no magic behind that it's doing other than the AI, but it'll tell you exactly what it's doing, I guess.

Yeah, yeah, that's right. You can watch the video, you can see what's going on and you can even interact with it in real time. So if you created a test, you can go into the test and say, hey, I want to see it run up to this step and then I might want to kind of play around and see what's going on with it and then resume it from this step to see it going. So you can kind of think of it as Like a. Almost like a test debugger experience.

Yeah, yeah, yeah. Like a breakpoint almost. And then you could start. That's pretty cool. Very cool.

Yeah. We even call them breakpoints.

Oh, okay.

Yeah. So you can set a breakpoint. Yeah.

Nice. Nice.

Yeah.

So I'm not that. I guess my old. Oldness actually worked there. Cause that's what we used to call it back in the day. All right.

Yep. There's another feature too, I think might be good for. To talk about with AI. It goes back to something that I mentioned previously, which is a lot of tests, sort of. Mobile teams are writing things in frameworks like React and Flutter, specifically Flutter. What's difficult about Flutter is that everything runs within a web view, which is true for React native, it's using web technologies, but with Flutter, it's using something called a Canvas element. And if anyone's familiar with Canvas elements, what that means is that you can't even generate selectors for Canvas elements because it's one big element. And then there's things that the web browser can't see that's happening inside of it. And so teams that are tasked with testing Flutter apps really, really struggle with automation for that. And so one thing that's really exciting about our approach is that because we're using computer vision, it's a black box. It should be a really fantastic experience for Flutter apps. So we're really excited about that, and that was one of the reasons why we took this approach. All right.

Yeah. So a lot of people worry about shadow doms, things that render that you actually can't probe and find out what it's doing. I guess another thing I guess would be helpful for, you know, how, like, you have these dynamic charts, like financial things. Does it help with that as well? Sometimes it's like Those don't give APIs, but if you could visually look at it, are you able to test those type of custom controls, then?

Oh, yes. Yeah. That's a great use case, too. So visually rich elements, visually rich applications are a great use case for it because again, we're just looking at the screenshots. So you could do things like, say, you know, tap on this data point within the chart. You can also ask questions about it. So not only will it take actions, but you can also perform assertions or extract data from it. So you could ask it, like, what's the value for the month of January? Or what's the latest data point in this graph? And it'll give you that data because it's just operating on the Screenshot.

You know, just random thought. Can you also use this almost like an exploratory testing tool? Like I used to have to test an application that had a patient, the patient was checked in and then we did procedures on. Could you use it? Say, hey, get up to this point. And then once it enters all the points, I just start interacting with the hey, do this, this and that. Does that make any sense? Is that something you see or.

Yeah, makes any use case you sort of. Were you thinking there that it's like sort of ask the AI to take random actions and see what happens kind of thing?

Yeah, like get to a point and then once you get to the point, you know where you want to get to like just start having it setting it commands in real time of things to try or explore.

Yeah, you could. So you can send individual commands to it and you have the option to keep those commands or not. I think though that scenario, Joe, it might be an interesting use case for like agentic workflows. And I think that's something. That's not something that we support today, but it's something that's definitely on our radar for the future, which is where you're handing more of the responsibilities over to the AI and that's sort of akin to what you're talking about, which is like maybe I tell it to go up to a certain point and maybe I say, hey, I want you to try to try some from the list of these things and report back and let me know what you find. So we don't have that quite yet, but yeah, I think you'll see where that in in our product and probably other products soon.

Nice.

Yep.

So I know with mobile testing, you mentioned performance, does it do anything with security or accessibility testing? Is that anywhere on the roadmap? Because I know a lot of people I've been talking to have been bubbling that up as a concern.

Yeah, not anything specifically on that now. Nothing beyond what the device grid would support. I agree though. It's definitely. And it. For some organizations especially, it's a really important requirement. I know that certain, you know, especially in government, you have to comply to certain accessibility controls. And then, you know, for really popular applications, you know, accessibility becomes, as your app becomes more popular, it just becomes more and more important. So nothing there right now but agree it's. It's an important aspect of testing.

Do you have any recommendations on how to integrate maybe mobile testing earlier in the pipeline? Is this something you still see as just a testing team that does it when they need to or as a something you can actually help incorporate into your CICD pipelines.

It's definitely something you can incorporate in cicd. The a big barrier I hear from customers and it sort of maps to if you think about organizations getting more mature in their testing practices is when do you decide to turn a test to be an automated test? Right. So organizations that are early on in their journey of kind of testing maturity will rely a lot on functional testing. They'll do more testing at the back end of the process. And when they're adding automation, they're really choosy about when they add it because they're worried that that automation is going to break it. Either maybe takes a lot of time to build it or it takes a lot of time to maintain it. And so they're really choosy about it. Where I think we best can help there is if you have an approach that lets you to create tests faster, spend less time maintaining it, you are naturally going to increase that automation coverage and it's naturally going to give you more competence to push it more into the critical path because you can rely on the results of that better. And so that's where I think we can really affect the most change. Nice. Yeah.

So I guess I have this vision of people when they work at vendors, they like have an R&D department. They're doing all crazy experiments in the background that we may not know about. So I always curious to know like where do you see mobile testing going in the next few years? Are there things you've been hearing about maybe you've been experiment with? Not necessarily that you're going to incorporate in the tooling yet, but anything that you see on the horizon that people need to be aware of when it comes to mobile testing?

Well, I think short term a lot of. I don't see there being a ton of changes in terms of the. I would say the biggest thing about mobile testing right now is that just the proliferation of different type, device types and devices that you can support. I don't see that changing anytime soon. I don't think there's going to be a situation like what we saw with, you know, 10 years ago or 15 years ago with browsers. There were so many different browsers you had to test on versus now it's basically just Chrome. I don't see that happening anytime soon for mobile. What I do see is that I think there's the AI piece and we talked about like I think that's going to help improve adoption for automation and mobile testing. I think mobile is going to continue to grow. It's already bigger than web testing as a market and is growing faster. I think that will continue. But what I think will be interesting, I don't know exactly how it will manifest is that mobile seems to be the type of device that would help you interact with an AI in a unique way versus a computer like a laptop. So things like, you know, Siri's been around forever, but there isn't really a ton of use cases of Siri that you would need to test in a given app. But if LLMs are incorporated into an app, every app, or there's AI functionality in every app, you might actually see more sort of voice enabled things that would require testing. Maybe the interface kind of morphs between from, you know, tactile interface more to directing it to do something or it running in the background. That's actually a lot. What agents are right is an app that runs in the background. So that actually might affect mobile more than it affects laptops in the next couple of years.

Interesting. Interesting.

Yeah.

I think I asked you every time you're here, but AI keeps evolving. Should testers or DevOps people be worried about AI still taking their jobs?

Yeah, I don't think you. I would be worried about it taking my job. I'd be worried that I'd not be keeping up with the trends in AI. It's a great lever on your time. I don't know how often do you use AI just in your day to day?

All the time. My wife says don't use ChatGPT for that. I use it all the time. I annoy her so much with it.

Yeah. But it's funny, I don't know how you feel. I keep finding use cases for it like we're planning a vacation.

Yep.

And you get, sometimes you get really fantastic recommendations on like restaurants or things to do and it encourages me to use it for different things. So I would say that if you're a tester and you're not finding honestly like thinking about use cases to use it and getting encouraged that it's helping you. I would be worried that it'd be left behind because it is such like, you know, lever on your time. But no, I wouldn't say that it's going to replace folks tata.

I speak with a lot of people. Some have internal, some have external grids. Sometimes you want to connect both. Why would someone want to do that and does reflect support it.

Yeah, so we definitely support that. We have our own internal grid that you can use straight away for your testing. If you don't have something like a browser stack or Sauce Labs or bitbar. But we do support connecting to the external grids. The reason why primarily is that some customers already have a grid. They've already vetted it. They might be using things like private devices that they've already invested heavily in. And so we did that to sort of meet our customers where they are. And it just makes it easy for them, those folks who are happy with their grid, to adopt our automation side without having to kind of rip out the usage of the grid that they're already using.

I guess because they use both or they have flexibility, say they don't want to have to keep adding to their grid. Right. Maybe they could start outsourcing some of the tests I need to run on specific devices to the external.

Right. So right now we only support either or. So you either connect your browser stack or Sauce Labs or bitbar, or you'd use our internal. Yeah, we're sort of making an assumption that the user is standardizing on one. Yeah. But it might be the case that users might want to use multiple. Yeah, so we might find the. I need to support that in the future.

Awesome. I keep finding them.

Awesome.

Cool. Okay, Todd, before we go, is there one piece of actual advice you can give to someone to help them with their mobile testing efforts and what's the best way to find or contact you?

Yeah, so I would say one advice that I would give is to try to incorporate AI into your mobile testing in some form of function. I think going back to what we were just talking about, maybe it's trying out Reflect, but maybe it's just something using AI to kind of think of different scenarios that might help you in your functional testing. As far as where to find our tool, you can go to Reflect run that takes directly to Reflect, or go to smartbear.com to learn more about Reflect and our other Smart Bear testing products.

We'll have all these links that you can follow down below. And for links of everything of value we covered in this DevOps Toolchain show, head on over to test guild.com p189. So that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain 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@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 to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

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 tester showing us secrets to behold.