Ultimate Guide to Selecting Test Automation Solutions with Anna Royzman

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way o the test Illinovation 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, in today's episode, I want to share with you one of our Automation Guild monthly community sessions with Ann Reisman, all about the manager's guide to selecting test automation solutions. And if you haven't already registered for our next Automation Guild Online conference taking place in February, I highly recommend you do by heading over to automationguild.com and registering today with the ticket. Not only do you get an awesome 5 day online event, but the community lives on long after the online conference is over, with an additional nine monthly community sessions like this one. So in this session, Anna Roisman, who is an accomplished figure in software testing and is the founder of a Quality Leadership Institute and Test Masters Academy, covers the essentials needed for decision makers responsible for test automation solutions. And it also shares a guide on how to choose the right automation tools to elevate your testing initiatives. You want to miss this episode? Check it out. Hey, before we get into today's show, I'm guessing you're probably someone that's tired of maintaining an in house automation grid, or you're struggling to scale your test due to limited device coverage. Or maybe someone who's ready to move into the landscape of automation testing. Am I right? If so, look no further because BrowserStack has a plug and play solution that could help you achieve your test goals faster. Introducing Automate Automate is a fully managed cross browser automation testing solution that provides you with instant access to over 20,000 devices to run your automated tests across browsers like Chrome, Firefox, Safari, and Edge. It also has extensive support for all the leading testing frameworks like Selenium, Cypress, Playwright and Puppeteer. Automate ensures full coverage for your tests. Choose from 3500 Device OS Browser combinations to run your tests with minimal latency. Powered by 19 global data regions, you can also get testing ready in minutes with BrowserStack SDK allowing to integrate your test suites to BrowserStack with no code changes. You also get a really cool summarized dashboard to know your test status alongside an arsenal of strong debugging capabilities that include a range of logs including video logs, text logs, Selenium logs, and many, many more. And there's a bunch of other debugging capabilities that give Automate the Edge, for example, interactive debugging that lets you interact with the website under tests while your tests are still running. It also has web performance reports that helps with generating Lighthouse reports and added assertions to test your web vitals. You can even test some of your more advanced user cases like payment workflows, two FA and network simulations as part of your testing suites, giving unparalleled accuracy to your websites and web apps. Sounds cool, right? But don't believe me? Try it for yourself using the link down below to see if it can help you in your testing process at scale. Also, I heard from the team of BrowserStack that there is a surprise within Automate. It's new experience coming to Automate that will elevate the way you leverage Automate to test, report and debug at scale. It is packed with next level reporting, debugging and analytics capabilities. They tell me it's going to offer a unified view of all tests executions, delivering comprehensive insights into performance and issues along with advanced debugging tools. And I'll be talking more about this in the upcoming months on my podcast and on my YouTube series, so don't miss out on learning more. Make sure to sign up today using the link down below to learn more about browser Automate because the update that I just talked about is just around the corner.

Thank you very much. It's been a pleasure and an honor to talk to people at this guild. I know that you are serious people and you talk about serious stuff. My presentation is for software tests leadership of people who make decisions of test automation. Just so you understand, this talk will be targeted to people who are decision makers. If you're not yet decision maker, stay learn. Because at some point if you have a career aspiration to go there, then definitely you have to know what you're doing when you be promoted to this role. If you influencer, if you a stakeholder to test automation then you should be here as well because I'm going to spill some secrets. Customer number one is the ultimate test automation strategy guy for quality manager. Imagine yourself buying a new car and you go into the shop and you say hey I want a new car and you have this all ideas in your like why do I want a new oh I want to go to drive fast and it's going to take me places I want to visit and it's my garage, it's ready for me when I want it. I can put the music, I can put automatic control, I can have heated seating there, I can drive my family and friends with me. I don't need to call taxi when going to airport. I can now Go shopping and put all bags in my car. I can use it for heavy loads. All those things that you have in your head. And then you're going to buy a new car. All right, so you bought this new car. Ah, it's time to go to airport. Sorry. The car is due for maintenance. All right. So it's not ready for me. I asked it for heated seat. It was too expensive, so we put air conditioner instead. Oh, but I bought a new drawer and I want to bring it home. It will not fit. You should pay for delivery. Oh, I want to drive my kids to school. We don't have protective covers. Your interior is going to be destroyed. I want to take my friends camping. Your tires are not suited for this road. Wait. I wanted my car to solve my problems, but we spent all the money on this fancy solution. Who is the customer of test automation? In the same way, who is the customer of that instrument, which is the car, the tool, your assistant that you use when you need to solve your own problems and to get you where you want to be? Obviously, the customer of this car is you. In the same way, the customer of the test automation is you. It is your tool. The test automation is your instrument, you the manager, because you are the decision maker. So the test automation solution must perform tasks that you intended it for. It must cover scenarios you prioritize, it must be functional in all the environments you identified, and it must be ready when you need it. We're going to be talking about strategic solutions and today I'm going to give you the strategy guide. But I want to go back to this very important slide. I want to reiterate. The only reason that you in this talk is because I want to reiterate to you that you are the customer of the situation you the manager use, the stakeholder is the customer. And as a customer, this instrument has to fit your needs. It has to be there when you need it. It has to perform tasks that you need. It has to fit in all the environments that you needed it to fit. And it must cover scenarios that you prioritize. If something is important to you, then it should be doing that. I'm going to give you this strategic solution factors first, and then we're going to talk about ownership. Because sometimes I've seen a lot of test managers who are not the owners of these solutions. For some reason they delegate or they assume that somebody else will do it for them or. And they got very frustrated because it doesn't perform the way it performed. So today assume that you in A very high rank school. I'm going to teach you how to define the strategic solutions or your test automation needs. So in order to define your strategic solution for test automation you have to understand your system architecture, your business domain, your SDLC software development lifecycle and release guidance, which is how fast you're doing the release. And you have to evaluate your resources, the skill sets of your people, the number of your people, the time, the technology and the budgets. Very important. If you are a stakeholder then obviously you deal with the budget and you make decisions on the budget as well. So first you have to have a good understanding of the system architecture. I put here the stock exchange architecture and as you can see there is a lot of different components that you as a trader, if you trading stocks, you probably know, if you're not trading stuff, you're not even aware how complex the system is. Putting test automation on it and just do it from like users to interface systems. It's impossible and it's not even needed. You have to break down into the chunks and where you can put strategically where you can put the test automation. Some of that will be integration testing definitely. But you probably don't want to do end to end system testing in automation unless you necessarily need to. But you can do some integration components into test automation. You definitely don't want to put everything all your testing on ui. Look how much happening on the backend. It's like an iceberg. So you don't really want to test everything through UI automation because it's useless. It's crazy. But you probably want to talk more on to test more on the backend on the order process block. You want to put some test automation on the data in the database. You probably want to put some automation into the messaging system. Messaging between your backend and the third party backends. And this is how you approach strategically the best automation solution. You totally never do it through ui. There are some systems where you should be doing through UI because that's the only thing you have. But when you're in a very complex scenario, then break it down. But you have to have a good understanding of the system architecture. This sheet has to be in front of you. All this diagram has to be in front of you. When you're making decisions on test automation you have to be confident on the business priorities. I put here four different businesses. One is on travel business, another social media business, the third one is medical business and the fourth is the entertainment business. What would be the priorities for each? In travel you will have reliability Is like a big deal for it. When the tickets have to be. When the flight don't go as planned then they have to be able to reschedule tickets. There is so much in travel and you probably know if you frequently traveler how much. Social media is totally something different. So analytics, statistics is something that is very big deal in the social media and finding bugs in that area is actually also a big deal because social media is used for business. Digital health aid, hospitals rely on it, all the health providers rely on it. The big deal for them is actually people lives. So it's. There is a additional layer of compliance on everything that you test for health and there is additional regulations. So you don't just provide your testing but you have to provide the documentation of what was tested and there's certain rules of how you do it. It's a life threatening situation if you make mistakes and find bugs in it. So definitely a different focus. So business priority would be on saving lives. Entertainment, streaming, right? You want to be uninterrupted. Entertainment is a big deal for uninterrupted experience and it should give you the choices it you have. Like your subscription should be working well and it should be working for you in different countries. So definitely each of these businesses have different priorities and you want to test. When you do your automation you have to put the focus on these business priorities because this will drive your test automation solutions as well and it also will drive your strategy and test automation strategy because it will be different for all of them. Then you have to feed your test automation solution into your software development lifecycle cycle or you have to change your software development life cycle which is okay if this is part of the. If you in charge of it or if you are influencer to change your solutions then go for it and change it to. So the test automation is not an afterthought which is often the case. But test automation is actually involved from the early stages and you can enable the teams to use the test automation when it's actually needed, not as an afterthought. What I have seen happening is okay, so yeah we have to develop those, automate those test cases but we cannot do it in this sprint because we're doing something else. So we're going to do it at next Sprint. What is test case automation for? If it's not for the team who is delivering then what are you doing? Then it's really a big deal. And putting the test automation as it takes time to do it's development like anything else. It has to be Part of your sdlc. For example, if you see over here, I put three different. I just googled for diagrams. Do you see anywhere where it says test automation? No, it doesn't. Right? It says testing. What does it mean? Testing. You cannot do like test automation after your implementation because you have to do deployment and you don't have time for test automation. So you have to be planned carefully because usually what happens is the test automation is either as becoming a technical debt or it's completely not correlated with your software development life cycle, which is it's bad. It means that it's not used when it needs to be used. So be very responsive to your sdlc. And where in this SDLC you want to put your test automation.

Very big deal is managing your resources. Resource management is a big deal. The any strategic decision. So you have to totally evaluate the skill sets of your people. You have to know what they're doing, what they're capable of. You have to know the number of people on your team or who can be doing the test automation. If it's not people on your team, so who is actually dedicated to test automation? How much time do they have? Do you have on the project? You need to understand technology because different technology requires different skill sets and you can leverage some of the technology if you're ready. As an example. So development is already building your front end with certain language, right? Say it's Java for example. It won't make sense to create a test automation solution which is more or less in Java as well. It doesn't have to be bad. What it gives you advantages of it is that the same developers that are coding, they could help you with solving some of your issues with test automation because you have like experts next door. So just consider it doesn't have to be, but consider it also the budget. You need to understand how much money you're spending on test automation. And big deal of test automation is maintenance. Because if you create a test and it's no longer valid with the for example, you have version number two of your software and you have to rework your workflows, then all of a sudden test automation is no longer valid. You need to change the test automation script. And it's a reality of any software development. So don't be surprised. It's not like disruption, it's a reality. The test automation solutions not hundred percent reusable. They have to be made and for the next release. And this work has to be taken into consideration as part of the story. It's not a technical depth, it's real work that you have to adjust your test scripts to the new features. It has to be done. Otherwise you can throw away your test automation work allocation. Who is working on test automation and when? There were some times when you didn't. You need some resources to put on something else. For example, you can have test automation team, but they need input from your testers and your testers are very busy doing something else. For example, there's hot release, you need to release now. So then somebody is waiting on somebody and you have to understand how you can reallocate work if situation like this. So you have to prepare for anything. Like any crowdstrike situation, you have to be prepared for project milestones. When you have to deliver at what time you already committed. And if you're a manager, you know that these are big deals for business and for your management. So the milestone, when you put the date on something, you have to hit this date. If you don't hit this date, you don't have a bonus, have something bad on your review, you didn't fit the goal. So milestones are always like those are commitment that you gave to your management. So just be aware of it. You have to deliver there as much as you can. You have to. And if you don't deliver to this milestone, then you have to explain why you don't and you better be persuaded on that. But always take into consideration any project that you committed to, all the milestones that you committed to growth opportunities. Some of you people will be. You have to put this into consideration, right? When you're thinking about test automation strategy, you have to think about people because people are working with it. Unless you outsource, then you don't have to worry about growth opportunities. People in your team, they would want promotion, they would want to change directions, they would want to acquire new skills for promotion and do use the test automation as part of your growth opportunities strategies as well. When you do planning for people, put some of test automation in there, get to the next level kind of situation milestones because you don't want your test automation to be in the back burner. Like assuming that it's always going to be working, you always have the people. You have to use the test automation as another step in people's promotion, for example, doesn't necessarily need to be. But if they say yeah, I want to master this, then make it as a goal for people and use it as the growth opportunity opportunities. Another thing that you want to consider, if you're a manager, you have to have a backup and in your growth opportunities. If people want to get to the level of management or leadership, teach them what I'm teaching you today. Teach them how to create strategy for test automation. Because it's a huge deal for everybody in QAO testing field. You really have to manage it and have a long term plans for all of that organization goals. So do know where your organization is going because if for example organization wants to retire some solutions, definitely research that. So you prepare because your test automation solution may not work in a new market and then be aware of what your organization planning to if you are in managemental leadership, you probably will be exposed to some of it. But be proactive about this because you have your long term organization goals aligned with your long term decisions. Okay, I'm going to be giving you four lessons Mastering automation strategy. We're going to go over all these four, but those four lesson is define declutter, decouple and all and we start with lesson number one. Define. I'm just going to describe you this exercise but you have to do it by yourself. If you already have test automation and yes you do, I assume most of you do just do this exercise just for yourself to redefine it. Define the purpose of test automation. Just write it down. What is the purpose of test automation? You'll be surprised because there are some assumptions that are like you will have to reveal them. What are the purpose of test automation for your don't just say that it has to say anything. Then you're going to compare to what you say to what it actually does for the purpose of test automation. What are the priorities of test automation? What are the most major points of their Test automation has to give you results Define measurements. How would you know that test automation is actually does what it's intended to do? How do you measure the success like by which measurements you would know that by which number. So whatever it is, you know that it does what you intended it to do. And obviously some KPIs doesn't have to be but if you are on it then use some of those too. This is the like very first step. You have to identify the purpose priorities, how you're going to measure your success, then declutter where to use automation in software development Life cycle There are different places in the lifecycle where test automation may be useful and where it has to be more or less performed. You can put like when you can start test automation, at which point you can start it in this as you'll see and at which point it has to be workable so solution has to be workable. It doesn't mean nothing if it's already done. If it's not working, then you have no solution. So in SDLC there is different. Obviously in life cycle there is different milestones as well. Where do you want your test automation to be started? Where do you want it to be performing? At the story level, at the acceptance criteria level, at the coding level, at the story testing of the spring testing of regression or release candidate testing. I can tell you now that all of these are different activities and test automation is not suitable for all of that. Sometimes with the storytesting you may don't need to put a lot of automation, but you definitely want to put more automation in regression. And if your UI is changing, but which usually is changing but your backend is not changing, or your database tables are not changing, then put more automation on the backend. That means headless driver. Or put your automation into the backend itself. And sometimes you want to put the automation on the database itself. You can do. It's called a golden copy comparison. So you pre populate the golden copy, then you and have a like snapshot of the database how it's supposed to be and then you run some tests and then you take a snapshot of your database after you're running some tests and you compare to the golden copy. That's another way of using automation for something which is not ui. Lesson number three Decouple. You have to use the best tool for testing various places, layers and stages. And what I just mentioned to you about the golden copy is something that you want to use when a lot of people using API testing into the API but you don't know you can test UI through APIs through UI. It's not a good idea, but I've seen some people doing it too. It would be great to decouple all your components and make specific tests. Use automation. Specific automation. Not one tool. It's usually not one tool doesn't fit all. But you can go away with like few tools and few methods. Make sure that you are testing the components directly. It's always useful, it requires less maintenance.

And in the long run it will save money as well. You want to look at the business workflow versus end to end testing versus operations workflow versus admin functions. And your test should be separate for the business workflow because this is high priority to the admin functions which is completely separate tests. Right? But if you decouple them then you could use different testing test automation solution for each of them. When you need it. And for example admin functions are a big deal, but you can test it manually if something's not working. But business workflow is something that you really need those results really fast because they are high priority and you want to reuse the business workflow automation in as your sanity check. So that is really a big deal. Business workflow admin functions is nice to have. Then you have to differentiate between acceptance testing, functional testing, load testing, failover testing. All of these are valid testing. But test automation should not be testing everything together. Decouple and also decouple in the phases Active development or release candidate or regression testing. Because active development is a great thing. But the things, a lot of things are changing because active development is discovering the solutions. Regression testing, making sure that your reputation stay intact. Whatever was working before should be working now. That's the goal of regression testing. That's your reputation. Active development is your excitement. Oh, we got new feature. Maybe nobody wants this new feature so we're going to change it in the next sprint regression testing here we already have this feature. Our customer knows about this feature. It better be working when we put something else into our system. Define priorities of what's more important for your test automation. Because you may not be able to do everything but do define your priority. Decouple as much as possible. And lesson number four, big lesson. You have to own it. Are you a test automation product owner? Are you the one who is driving the test automation product? What does test automation do? Test automation is product as any code, right? What does it do? It has to be doing something for you, right? Do you have decision power over development, delivery and Persona? If you don't, then make friends and you have to have an influence to the decision being made otherwise this test automation solution will not serve you any good. Do you exercise a strategic influence which is mentioned sometimes? If you're not in charge of something, then get trained on how to influence people and how to negotiate for what you need. Are the team goals aligned? Sometimes the team goals. The test automation team is separate, it reports to somebody else. But you are the customer. But you have no exposure to like what this team is goals are. And I've been the situation. Everything that I'm telling you is from experience. Because when I sometimes came to the automation team, I say I need this feature automated. They say no, but we're automating this. Why? Because our manager said so. So that's how it was. And then you have to persuade the manager. But you have to have a way into prioritizing the test automation work and if you don't then start working in this direction because it's really you have to own some of the solutions and be the decision maker and a lot of this test automation solutions. Six steps in picking test automation solutions. True. As I mentioned before when we just started when I said the strategy. First of all, set your goals. You have to understand what you're using test automation for in general. Like why do you use this tool, what do you need? And be honest about that because go one step, a few steps beyond the obvious. Okay, Just really set goals of what this test automation. If your goal is to please the higher up manager, then it could be your goal. But I hope it's not because they would be pushing you and putting some money into some solutions that don't work for you. So set your own goals. Why do you need test automation and where do your research? Spend more time on research or different tools, solutions and how it fits into your own workflows. So don't just take any word for granted. I have seen a lot of salesmen who say yeah, it's going to do everything for you. No, it's not true. Take your use cases, put them through that, whatever the demo is they doing for you and let's see how it works for you. Okay, do your research. There is a lot of tools on the market, huge amount of tools on the market. Evaluate, do a comparison of how much of this tool can cover your needs, how much you need additional internal solutions. Maybe you end up with just doing internal solutions by hiring somebody in the team and do homegrown everything altogether. So evaluate build versus buy and in different areas as well. I mentioned some of the domains where there's some engines which you don't create yourself like in trading, then you will have to buy that the services too. So evaluate that as well. Any third party integration you have to evaluate how much of test automation will be covering that estimate. Very big deal. So implementation of everything in test automation takes time as any coding. It's a coding activities so it takes time. So you have to estimate how much time it will take until it become fully functional. In my company there was one time a project where we decided to go fully automation. The whole company was on board with it. They shut down the releases for six months and all developers were doing only test automation. Honest, this is the. Honest, this is my experience because I was the leading the QA effort on it. I was writing specs. This was the very first time in my life I was writing specs. It's really hard. But I was the owner of this test automation solution and all the developers were dedicated to just doing that. So you have to estimate what your implementations and going forward what are the efforts of test automation will take, how much effort they take, how much money they will take if there is a support third party and how much time it will take to continuously do test successful test automation going forward then you have to select. So select it. Look at what resources you have and you need somebody to be maintaining. It's better to have in house. So if as I mentioned about the languages, sometimes you want to pick up the language that your team knows or some people or developers know or you don't need to like retrain everybody on like new language that nobody knows about. It's a decision to be made. We for example in my team we've been using Python because it's more kind of tester friendly than Java. But when we had our dedicated automation specialist who is Java developer, then we said okay, whatever, just write your whole driver in Java because he can. So it depends of like you have to evaluate your resources and going forward don't dump on unsuspecting people something like completely new. And the very big step later is you have to hire, train or outsource. You have to know who is going to be there to pick up the bill. Whether you need to hire people with new skills, where you have to train your own and delegate or hire in the team or promote somebody into that role or you have to outsource and there is a lot of outsourcing solutions. So definitely hire, train, outsource and do calculate because this is your budget decisions and hiring decisions as well. Okay, next I want to briefly chat about the AI and test automation because 2024 September all major tools already are equipped with test automation. AI. By now all the major vendors I know they already put the release press releases that part of their solution is AI. So it's not something that you will need to research. It's already there, all the tools are equipped with it and if they don't then they are not competitors on the market. If you want to hear a secret from me then because they all going to push it on you and your management's going to push it on you. Use AI solutions to increase productivity, but don't take any words for it. Bring your use case. Bring a use case to the evaluation and use AI solutions to increase productivity. Because most of the things that AI claims to do generation it can generate a lot of garbage for you. Definitely put IT in your use case in IT and understand how it's gonna save you time or give you more bandwidth or whatever it is. But just don't take it for the sake of it. Okay? Only if it increases it really increase your productivity and it can. Okay, I'm going to give you two examples. We don't have much time. So very briefly, two examples of the how to use the test automation AI to increase productivity. Because trust me, if you're a decision maker in 2024 on test automation, you will have to deal with AI. If you don't, then I don't know where you work. All right, this is how to deal with AI. Look at USDLC and C, where are the productivity gaps? And talk to your team and you probably know already what is slacking here. So you have to know that like different steps like what's done, spec story, acceptance criteria, BDD coding, testing done, that's sample. It doesn't mean that it's yours dlc. But there is obviously somewhere there is like productivity gaps. And we're going to look at two places where there's productivity gaps. One productivity gap is indefect prevention which is the collection of requirements. Incomplete requirements, wrong requirements, poor communication, changing requirements, unclear requirements are usually the productivity gaps. And then you have to spend and don't take anything for granted, just evaluate where you spend most time. Okay, this is one of the huge reasons where the productivity gaps are exist. Sometimes it's technical jargon, you don't understand what this guy said or they don't ask the users and all of a sudden they create requirements that not user are accepted. So then they need to change it again. There is a AI solution which validates the requirements which is shift left. So it definitely increases the productivity. And this is the big deal. Let's look at defect detection challenges. What could be possibly defect detection challenges and your test automation. This is for you. Test automation decision maker. Defect detection challenges are could be in communication between the spec and the test. There could be a communication gap. People may have lack of skills on resources on doing for test. So defect detection is the function of test automation. That's why it's here. And when we talk about lack of skills of resources, we could talk about the lack of skills on resources of test automation. Sdets, test automation specialists, how to deal with changes. Dealing with changes is a big deal. It takes time. Always there is time constraint. How much can you do in a certain amount of time? Incomplete test coverage is a big deal. So you can put your test automation in wrong places. Compatibility issue is a big deal because your test automation environments may be not the replica of real environment and then it could test, could pass in one environment and like with synthetic data and totally fail in the real life scenario and then lack of clear pass fail criteria, which is a huge deal for test automation because sometimes you don't know if the test is failing for the right reason. Okay, in summary, finding AI solution, the same thing that you do with test automation, but a little bit different approach. Don't just take AI because it says AI. Okay, first of all identify the gaps in productivity and then do you research what AI can offer and if Genai, it can offer generation but it cannot offer a lot of validation.

Unless you put it in there. And also it does hallucinate, it does, it's a feature of it, it's not a bug. So you have to be aware of drawbacks. It's not about drawbacks or AI, but be honest about it. It's not intelligent, it doesn't sync, it doesn't have logic in it and it doesn't have mind. So no, it's not an intelligence. Be honest. Do your research about what AI can offer and where it cannot replace, which it cannot, and then you have to supplement. You have to introduce AI for productivity, but not for replacement. Somebody needs to have a brain to AI. AI is collaboration tool and it can do some tasks fast, but it doesn't, it's not going to sync for you. Same thing with Copilot, by the way. It can generate the code for you, but you have to test your code yourself. You have to watch what it's doing for you. All right, so no, it's not a replacement, it never is. If your management wants to replace people with AI, resist. It's not going to replace it. Never. You have to understand AI limitations, do your research, understand where gen AI is good and where it's not. A lot of things like garbage in, garbage out. You have to understand that AI works with data and it's trained on the data that it's been fed. So you have to really understand where the data sources are, where it's coming from because wrong data sets will give you wrong results. It's as simple as that. It doesn't have a brain, it's not going to link or it's not going to do any selection. You have to train everything to this machine and then once you did all your homework, you have to find the best tool on the market that fits your needs.

Thank you Anna for your automation awesomeness. Links of everything value we covered in this episode, Head over to test guild.com a528 all right, so that's it for this episode of the Automation Testing Podcast. Once again, I'm Joe. My mission is to help you succeed in 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 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 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 o the Test Guild 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 tester showing the secrets to behold.