AI-Driven Manual Regression: Test Only What Truly Matters With Wilhelm Haaker and Daniel Garay

In a land of testers far and widely journey, seeking answers, seeking skills, seeking a better way. O the testkill Animation Testing Podcast Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the testicle of nature Testing Podcast.

Hey, is your team still slogging through massive regression suites, feeling the pressure of shortened release cycles, or wondering how to trust what's safe to skip? If so, this episode is going to save you hours, maybe even days on every release. Today I'm joined by Wilhelm and Daniel from powersoft, and we're digging into something every tester deals with, but very few actually optimize manual regression testing. Listen and discover how to run fewer tests while staying confident. Nothing critical slipped through. Why are most teams still guessing what to test? And how can data finally replace those guesses? And how do you know exactly what manual tests or automated tests are impacted by each code change? Wilhelm even walks us through a real world example using powersoft's continuous testing platform, showing how code coverage and test impact analysis completely reshapes the regression process. If you've ever worried about missing a defect that kept you up late at night, or wasting time retesting everything just to feel safe, if so, you're not going to want to miss this one. Listen all the way to the end. Check it out. Hey, before we get into it, this episode of the Test Guild Automation Podcast is sponsored by the awesome folks at PowerSoft empowering QA teams with data Driven Test impact Analysis. If your manual regression cycles feel too long, too noisy, or too risky, powersoft's test impact analysis gives you clarity on exactly which test matters. By mapping real code changes to specific test cases, teams can cut redundant testing, focusing the efforts and releasing with more confidence. But as you know, I always say, seeing is believing. So try for yourself using that special link down below. Support the show and let me know how it worked for you guys. Welcome to the Guild.

Hey, good to be here.

Good to be here. Thank you for the invite.

Absolutely. Really excited about this topic. I know we're going to go over a lot of people still struggle with manual regression testing, what the challenges are, how to get ahead of it. So I think this is a really timely topic, especially in the age of AI. I guess before we get into it, maybe a little bit more about yourself. So, Wilhelm.

Sure. Yeah. So Wilhelm Hawker, I'm the director of solution Engineering here at Parasoft, focused on our functional solutions. So everything from API testing service, virtualization, code coverage, and Happy to be here today.

Great to have you. Hey Daniel, how you been?

I'm good, I'm good. Joe. So I'm director of QA here. Been in the industry for over 20 years, which is crazy to think, but it's been 20 years now. So managing the team here in the US and Poland, responsible for the metrics that we need to meet on each release, we obviously have a good collaboration with development and obviously leading the collaboration moving forward within the QA team.

Love it. So you mentioned you've been doing this for 20 years. I've been doing it a little bit longer. The funny, the topic we're talking about is manual regression testing. Why is it such a challenge? Especially as we as releases get faster and faster, especially with AI, with vibe coding. I've been vibe coding and I just, I go right to my production. Even though it's not mission critical, I should know better so I can imagine what people are doing in the real world. So maybe a little bit. What, what makes manual regression testing so challenging? Still to this day, with fast release.

Cycles this industry is always talking about, you know, oh, well, manual regression testing is going out the door. But I mean, there's always still some form of manual regression testing, right? And when you're releasing, you know, the first thing you think about is scope of what you need to manually test. I mean, you have a large set of tests that you need to actually execute and run, but you only have a small amount of time. I've never heard upper management come to me and say, hey, you know what, you have all the time in the world. Make sure this release is good and we're good. I mean, I don't know, I've never heard those words. I don't know. Wilhelm, if you or Joe, you have. But from, from the QA side, I've never heard that. So it's about defining the scope of, of manual testing, the test that you want to test to make sure that quality of the product is at a solid state.

Right.

So, so you, you know, always remember Q from QA perspective, it's a black box, right? We, we don't see the code, we don't know what changes under the hood. So we have to define the scope of testing at with our experience, knowing, with our experience, our knowledge of the product and from there try to fit it in that time frame that upper management gives us for the release. Right? So, so that's always the most difficult portion of it is defining that scope within that time frame because that time frame is always minimal. So.

It'S just trying to reduce that amount of Stress and everything else trying to get that in there. So I mean, in my opinion, that's always the most difficult part is defining that scope and hitting all the spots that you need to hit.

Right. And I think it's not just the time frame also, but the how often you're doing testing as well. And it's not always just a normal release cycle. Right. Sometimes you'll see a bug fix that needs to go out quickly into production and it's not your normal release cycle. And so that timeframe is even more condensed. Right. In those scenarios. And so that time constraint really forces teams to sort of think about that scope. Right. Or that's that subsetting of the tests very critically to balance. Right. You know, how much testing we're. We're able to do to fit within the timeframe versus, you know, what is the perceived quality that we can try to reach.

So do you still see testers trying to justify why they need to do more regression testing? Is this still a hard sell? Like a lot of times when I was working, they started more as like a cost center rather than a value add. How can we flip it to say, you know, it's needed and we're helping, we're adding to, I don't know, ROI or something in the long run? Because what we're doing is baking in value and necessarily taking away precious time for you to get it out the door.

I think that that depends on the project and the company and industry to some degree. Right. You know, everyone has a different risk tolerance when it comes to defects of their software. You know, certainly I think that's an easier argument if someone's going to die.

Right.

If there's a bug and if it's, you know, like a hobbyist vibe coded side project that has low risk. Right. Then the tolerance for defects. Right. Just test in production, like why bother? So I think everyone has a different answer to that question. Right. Depending on what is the software that they're testing.

Well, I think risk is the right answer. So that's a good point because like you said, if you're vibe coding something like me, who cares doing a production, but I used to work at Healthcare, couldn't do that. Hopefully they're not doing that now.

Right.

For sure. I think it's all about minimizing the risk. Right. I mean, that's the whole point of quality assurance. We're trying to minimize the risk as best we can. So the best you could, you know, I mean, the whole purpose of QA is to minimize the risk. So if we could do that the best we can, then we go forward from there.

Speaking about risk, a lot of times testers think if I run X amount of tests, thousands of tests, then it'll be better. But nowadays, because we do need to release faster, how can testers maybe run fewer tests but still feel confident that nothing critical slips through? Is it because they looked at risk first and they know these tests cover these risk, or is there any kind of rule of thumb that you use?

It comes down to balance, balancing the time, right? And so to sort of be able to cut down how many tests you're running and still maintain high confidence, it you really have to have a data driven approach. And so one strategy for kind of applying data to this problem of scoping what tests to run appropriately is to leverage code coverage. And you know, normally, code coverage, you think of it as a developer metric, right? You, you capture it when you do unit testing. But code coverage can be captured from any type of testing, right? Even system level testing, browser testing. And so measuring code coverage while tests are taking place lets you sort of have a data point so that when code is changing from, you know, one time you ran the tests to now the test environment has a new build, right? Some code changed in that build. You can look at data to say, okay, well, based on what code changed from the last time I did my testing, what subset of tests are impacted by the code change, Right? So it's not, it's not vibes, it's not feelings, it's not committee, right? You're looking at code coverage data and code changes and the system tells you like, these are the tests that have been impacted. You should probably rerun those.

All right, sorry. This used to be my pet peeve when I was an automation engineer. They check in code, right? And they say, run all your tests, right? You don't know, you could have like a test has no impact whatsoever, but it fails and you're trying to debug it why it's failing but has nothing to do what was checked in. So it doesn't, and I'm not saying it doesn't matter, but it kind of makes the really noisy what's going on. And a lot of people miss out what you just said. Like, it'd be really nice to know that you checked in this code. And therefore test A and B and Z, we'll be able to test that, that, that that particular code change and that would save time. Am I right or wrong? Why aren't more people doing this?

I think part of it is there's some setup involved and with the open source options that are available, it's kind of limited. Right. Code coverage is always thought of as like a reporting metric. And so this is kind of like a unique or interesting application of code coverage to kind of solve a problem around test optimization. Right. Or like test subsetting in a data driven way. And so it's not really about like from a tester's perspective, worrying so much that there's code coverage in the picture whatsoever that's kind of in the background. Right. From the tester's perspective, it's like, what are my tests, when is there a new build in the test environment and what tests do I need to rerun? So the fact that code coverage is being collected in the background is sort of irrelevant from the tester's standpoint.

I don't think it's irrelevant. I think it's just an additional benefit. Right, Wilhelm? Um, I mean, yeah, we're not considering that, but it's just an additional benefit because the higher the code coverage, you know, we, we know that the, there's less risk involved when there's higher code coverage doesn't mean we have to do less testing, it just means there's less risk involved. So. And again, you know, as I stated before, it's all about reducing the risk. So we want to reduce that risk.

100% agree. So Will, I'm going to put you on the spot. I was wondering if you can actually walk us through a day in the life of a tester. I know we talked about test impact analysis, like how that all works. What do they focus on when they're manual of regression testing, A real life kind of view into what that might look like.

Okay, perfect. So here we're looking at a list of tests that I've imported for my demo application, Parabank. You've seen a Parasoft demo before, you've probably seen a lot of Parabank.

And so the question is, okay, I, I did a Test run on V1 of my ParaBank system yesterday, right. And I've got most of the tests passed and now I have this request loan test that failed. And so let's think about it from that perspective of, you know, we don't have a lot of time. And now development pushed V2 of Fairbank into the test environment. And I mean this is a demo, right? So it's only a few tests in here, but you could imagine the test suite could be much larger for a large system. And so the question is, I can't rerun Everything. What should I rerun? And so that's what the system really allows us to identify. And so here I can see that for my bill pay test, that's been impacted by code changes. And the other tests are kind of inheriting the test status from the previous test run. And so as a tester now I know that I don't have to run transfer funds or new account test. I just have to focus on bill pay and probably request loan because that test failed before and hopefully the development fix that. So if I were to come in and say, okay, let's, let's do a new regression session and this is for V2 of Parabang. And.

And I start that session, I go, okay, well I want to start my bill pay test. So I start the test and I come over and I start testing my application. And so what's happening in the background while I'm interacting with my parabank application? Here we have a coverage agent that's deployed with the application. So all of the code that's being exercised as I'm performing these actions is being associated to this bill pay test. So now stop the test, say we passed, come in and okay, let's do request loan.

And we'll, we'll fill in some data here for request loan. And so some things to think about.

Parallel testing is supported. Right. So if you have a QA team and they're testing the application at the same time, you want to be able to differentiate, right. Which code coverage is coming from which test or which tester. So that's something that is part of the solution. Microservices architectures are supported as well. So if you have several services and they're all kind of grouped together as the system that you're testing, it's not like one monolithic application container. All right, so we'll trace code coverage through those as well. Yeah.

So you mentioned something about testers, multiple testers, what they're working on, because you can run in parallel. I used to work with the, in a company that had eight Sprint teams. And so there was a lot of people doing the same test, but they didn't necessarily know because they weren't talking to each other. So would this be able to pinpoint, hey, we're running all these tests, but you know, these eight teams are running 40% of the same tests that we could just get rid of and make the Sprint even quicker almost for, for the, the verification at the end of.

The validation, certainly we, we measure that data or collect that data to do analytics like that. So you Know, one part of the solution that I'm not showing here is sort of all of the reporting, right. Of test results and code coverage.

From a test impact analysis perspective.

We'Re.

Really just focusing on, you know, what tests do I need to run or rerun. There's a whole other reporting side to this that we could, we could get into. But yeah, I mean, we, we collect the data, so that's something you could do.

Does it know about duplications? Because you were just recording a step. So we'll know like, you know, you don't need to run this other test because it's basically touching the same backend or the same code that was checked in. So it's no need to do all these tests for that to recover with this one.

Right. So that's, that's, that's part of the data we collect, right. So like each test case that we run with the solution in place is we see what code is kind of getting associated, right to that test case. And so you could imagine if you have like lots of overlap, right? We have that data to show the overlap.

But in terms of kind of coming back to that scenario of I don't have enough time, right. And I need to figure out what are the right things to test.

Now that I finished this test session for just bill pay and request loan, I know that for the current version of Parabank, that's in the test environment I've covered or I've verified all these test scenarios are passing across multiple builds, right? So some of these tests were verified in V1, bill pay and request loan, they were verified in V2, and I can be confident that I don't need to rerun these other tests in V2 because the code didn't change, right. For those, for those tests between those two builds. And so that's really what gives you that optimization and confidence to say, well.

Maybe I should consider bringing this into like the Sprint activities and not just doing manual regression testing sort of at the end, right. If, if the system can tell me like, hey, you know, in each Sprint development is working on, you know, these set of user stories and from our large suite of regression tests, we know which ones to rerun based on code change. You might even be able to start bringing manual regression testing earlier in the process as well.

What I like about this, I know a lot of teams, they actually have new regression, new code every day. So it's almost like you can save so much time because, you know, okay, we have all this new code every day, but I know this, this, this code is the only code that changed that I need to really test. Right. Am I following along correctly?

Right. And that's why people try to automate tests. Right. With automated tests, it's easier to keep up with the rapid change. But as Daniel was saying, you know, manual regression testing still happens in many projects. You know, we were at a conference recently and I was up on a panel, and I asked the entire room, I said, hey, raise your hand if you're working on a project where you do manual regression testing. And every single hand went up in the room. We were kind of surprised. So, despite AI, Automation automate everything.

I.

Think we still see that manual regression testing is a part of many projects. And so how do we optimize that as part of the overall strategy? I think can pay some dividends for a lot of people.

Yeah, but even as automation engineers, Right. Even automation engineers have to do some form of a manual testing before they automate everything. Right. So even automation engineers are doing some form of manual testing. So, you know, you have to keep that in mind as well. I mean, everybody's doing some form of manual regression testing, even though, you know, our industry's like, oh, you know, automation's getting rid of manual testing, AI is getting rid of manual testing.

Sorry, I had to put my glasses on so I could.

But, yeah, there's always going to be some form of manual testing going on, even though I know everybody keeps saying it's going out the door.

You know, it's a good point. Even people don't realize automation testing is expensive, especially when you need to do maintenance if you have, like, thousands of tests that aren't necessarily as stable as you would think. So even though people say manual testing is expensive, this seems like it could almost reduce automation testing as well. Because once again, you're only focusing on the tests that really need testing. Does that make sense? Is that on the right track there?

Yes, exactly. I mean, the whole point.

Of test impact of this, which is test impact analysis, is to help the tester visualize, to see, okay, this is what's impacted and this is what's not. Right? You visually see that. You visually see that. So you have that confidence.

Of looking at it. And I mean, as QA engineers, when we're scoping out what we need to validate and what we need to test, we're not guessing. I would never say it's more we're using our experience, where we're using our experience with the product, with.

Our knowledge of the functionality, and we define what needs to be tested. And we may even reach out to developers and say, hey, do you think this is what needs to be validated? But with this, it gives us the ability, as Wilhelm mentioned, it's data driven, right? It's data driven. So just like everything else is data driven. Code coverage, software development, it's data driven. I mean, all, all these industries are data driven, right? Baseball, I love baseball. Data driven, right? My Dodgers just won the World Series. I had to throw that in there. But everything's data driven. Now you could say manual testing is data driven, right? Think about that. It's data driven. So now from a manual testing standpoint, you could see, okay, this is what it's impacted and this is what's not impacted. So now you, you could actually tell what you need to validate. What, what you don't have to worry about. It's just from a QA perspective, I think it just, it just alleviates so much.

Of the stress and it gives you just some more, such, more confidence in what you're actually validating is what you need to validate, right? You don't have to worry about all these additional items. This is what you're testing. This is what you, this is what will reduce the risk, which we talked about. And you move forward and you have that confidence because, I mean, Joe, I mean, you don't, you don't understand how many, like I said, I've been in this industry so many years, you know, when I test and I'm done, and I'm done, right? I have sleepless nights sometimes. Like, did I let something go through the cracks? Right, right. Everybody has that. And that's just, that's. I mean, if you're not, if you're not involved and you're not dedicated with what you do, then you might not have a solution.

Advice.

I do. I do. Every release. Like, I'm just like worried about it. Like, did something fall through the cracks? And hopefully this reduces that. That's the whole point. This, this, I'm not saying this is going to be the end, all end on solve everything, but it reduces the risk.

So we're talking about manual testing. But doesn't it help with automation testing? Because, you know, you don't have to run these automated tests. I mean, even though we're talking about manual regression, I would think AI can create thousands of AI slop tests of, you know, what they say you need to run. But I mean, unless you have this visually to say, no, you just need to actually run these tests because this is the only one that was impacted. It's going to save time, the whole team, I would think.

Yeah, that's, that's very true. Yeah. The solution we're talking about today, it's, we've been primarily talking about manual regression testing, but there's nothing that stops this solution from being applied to automated tests as part of your pipeline as well. You know, when I think about, you know, what you were saying earlier about.

You know, automated tests also having a high cost. You know, if I, if I look at those selenium test frameworks, the even playwright, the new kid on the block, you know, it's still a lot of maintenance work as the number of tests you have grows and so, you know, reducing, okay, for each build how many tests I run kind of in that same data driven way. I mean, not only does the test run finish faster and feedback gets delivered to development faster, but also the amount of maintenance work that you have to worry about for any given build also goes down. Because even if you have some tests that are, you know, they need updating and you know, they, they need some maintenance, maybe you don't have to worry about updating them right now because they, they aren't impacted and you can update them later when you have more time. And so these tests need to be rerun. So it helps the automation engineers be more focused. Right. Getting the right automated tests to run quickly, reliably as well.

Right. What Daniel said, being data driven, I think it's helpful because a lot of times as testers, you're kind of guessing right. If you're, you're kind of running blind, you're kind of guessing like, okay, this, this code was, it was introduced. So I, I assume it's going to impact this and that. But a lot of times you're wrong. I don't know if you ever done model based testing. A lot of times a model is completely not correct and then you have correct, you have incorrect assumptions coming out of it. Testers, developers and tourists for not giving good estimates of how long it's gonna take to deliver something. I assume this would help with that as well.

Right?

Cause now you, like Daniel said, you have real data to say, okay, I know I don't need to run three tests rather than 20. So therefore it's only going to take two days rather than 20 days. I don't know, I'm making it up.

Yeah, yeah, it's, it's completely data driven. You know, I mean, as, as QA engineers, I mean, we're, I always look at it, we're kind of like the last line of defense. Right, right before it goes out to the public, it kind of falls on our shoulders. So, so this will help that. I mean, it's just, it's just eases the whole portion of our testing to understand, okay, you know, what exactly has changed, right?

We have data behind it.

It's not an educated guess because essentially that's what we're doing, right.

When we've defined scopes of validation, when we're testing, they're educated guesses when you really put them, you know, when you really get down to it. Now, now at least it's data driven here and we've reduced that and, and hopefully it gives them some kind of confidence that, okay, you know, we, we covered what we need to cover and we, we move forward. I mean, you know, we, we have to continue to move forward because we can't just stay static.

Right?

We're moving forward and, and we're going on from there.

All right, so I'm a bad host. Before Wilhelm even showed his screen, what were we looking at? What is this tool? I don't think we probably even introduced what the tool was called.

I touched base on it, but Wilhelm, I'll let you talk about it.

So we're talking about Parasoft CTP or stand, which stands for continuous Testing Platform. It's, it's part of our larger suite of products that covers everything from service virtualization, API testing, and more. And so there's a specific capability for test impact analysis. And so what I showed earlier, we're looking in the CTP.

From kind of the manual tester's perspective, but also automated tests, like I said, are supported as well. Right. So whether you're, you know, a Playwright user or Selenium or, you know, pick your favorite automation tool for testing, we have APIs that you can plug into your testing process and.

Kind of enable test impact analysis for any, any testing that you do.

All right, so if someone's listening to this, they're like, oh, this sounds incredible, but will it work for me or how hard is it to implement? I mean, do they need to have your whole ecosystem? Is it, can they, how hard is it to get started? What does it support? If they use, say, C Sharp or, you know, Java, you need all these type of questions. Python, what does it work with? How hard is it to get up and running? Set up?

Yeah, I can answer that. So.

Since the solution is based on code coverage, we have coverage agents that are language specific. And so today we support Java and C. So, right. Spring boot Spring applications, very common in the. Net world. We see a lot of usage as well. Like I was saying, from a test framework perspective, it's test framework agnostic. So, right. You can kind of plug it in with any test framework.

And then from a setup perspective, ctp, it's a web server, supports kubernetes. So if you want to deploy it in a container in your environment.

It'S a web app. Right. Have your users log in and import their tests. Right. Maybe you have manual tests that you've defined in Jira X ray or Azure DevOps test plans, for example. So you can export those tests, import them into ctp, and then start the journey of collecting or measuring code coverage from the test sessions that you perform. And then have the system tell you, hey.

We deployed version two of the app in the test environment. The coverage agent needs to be deployed with it. So there's some DevOps work with a engineer that's responsible for deploying your application in the environments. And then once our coverage agent is kind of part of that deployment process, CTP talks to the coverage agent, finds out what changed, and goes from there. Right. In terms of telling you which tests are impacted. So not, not a. I mean, there's some pieces involved to, to get it deployed, but pretty reasonable, I think.

Very cool. All right, so I love speaking with vendors. Just because you talk to all the verticals, you know, a lot of times people are just pigeonholed, looking at their own thing. They don't see what others are doing, what they've accomplished. Have you have any, any, you know, what, any big wins or that you've seen teams get out of this tool? I don't know. Savings, time savings, quality or something else.

Yeah, so I think time savings and improvements on, on quality are kind of the, the obvious ones to think about.

And, you know, when you think about reducing how many tests that you need to run and being confident in the cuts that you make, you can actually better utilize that time savings. Right, so more exploratory testing. Right. You know, more time for developers or testers and developers to.

You know, test a particular area of the application more deeply or more critically. So that time savings doesn't necessarily mean, you know, drinking a Mai Tai on the beach and not working as much, but it could mean. Right. Or, yeah, I mean, it could, but usually it means like, hey, like, we can, we can focus more. More deeply in certain areas. And as to Daniel's point. Right. Work on reducing the risk even further. And I think, Daniel, you said it best when it came to sort of like the role of the tester and stress and stuff. But you know, I've, I've seen that be a big win as well.

Yeah, I mean, Wilhelm touches base. So he touched base on the stress point. I mean, you have two aspects of it. You have, from a company perspective, you know, you're saving time and you're improving quality. But I mean from two, a perspective when you're trying to get something out the door, the product out the door. Right. I mean that, that's generally speaking, that's the more stressful, stressful time for the engineer, the QA engineer, whether it be a patch release, the major release, minor release, whatever it may be. So if you have data driven information that tells you this is what needs to be validated, it at least reduces this. I mean, in my opinion, it reduces my stress in that. Okay, this is what needs to be validated. This is what the focus is on, right? You get that peace of mind, right? From my perspective, you get that peace of mind that, okay, I'm good with what I'm covering. So from an engineering standpoint, you have that peace of mind. But from a company standpoint as well, you have two aspects, engineering, the individual and the company. The company's saving time because now that engineer could spend additional time doing other tasks. Right? So you have that time perspective and they could, you know, if you need to improve additional aspects of the quality of infrastructure, whatever it may be, you have that. And so, so the company's benefiting from it and also the individual. So there's two aspects of that.

Okay guys, before we go, is there one piece of actual advice you give to someone to help them with their automation, manual testing efforts and what's the best way to find contact you or learn more about Parasoft CTP?

All right, I'll go first. So Parasoft.com we have a lot of information, a lot of extra videos, blogs, white papers to check out on test impact analysis topic, testing, test, automation in general.

So you can reach out to us there, set up a trial, get a demo, come talk to us. We, we'd love to hear, you know, what you're doing with testing today.

And I mean, obviously parasoft.com, we have our products there and everything, but from a QA engineer, you know, I've gone started in tech support, moved up to QA management director. I always tell my QA engineers, stick to your guns, right?

You know more than you think. You know, work with development, you know, you can't, if you can't work with development, then there's something to be said with that. I mean, the great thing with Parasoft, we have a great collaboration between development and qa. If you don't have that work with that, you've got, you got to have a good collaboration with development. Otherwise QA just, it's just, it's, it makes it just that much more difficult. Work with development.

Be confident in what you do and continue to QA and, and, and, and you know, respect yourself and move forward. You know, that's what this industry is about. So that's my, my view.

Love it and I highly recommend everyone checks it out using that special link down below. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode head on over to testguild.com forward/a5 69 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, 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@test guild.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.

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.