Low-Code vs. No-Code: Which is better for Automation with Larry Goddard

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and Welcome to episode 421 of the Test Guild Automation Podcast and today I want to share with you a webinar I recently did with Larry Goudard, who is an automation architect and creator of the classy JS Automation framework and also the folks from Inspired Testing hosted by Jian, who is a consulting and architect at Inspired Testing. I don't know if you know, I may have said this a few times, I'm always uncomfortable talking as a speaker and not a host, but Larry does it really well and he drops some real gems that I think you really want to hear, so you definitely want to listen all the way to the end. Also, I'm in the early stages of Planning Automation Guild 2023 and currently the call for speakers is over and we're now in the voting stages of what session you want to have at the seventh annual Automation Guild taking place February 6th to the 10th of 2023. So all guild conferences, if you don't know our attendee led and we take a really democratic approach to find out what sessions you want are things that you're struggling with rather than me making assumptions about topics and titles that are going to give you value in the new year. So the way to do that is to vote on our sessions and voting on the sessions and the speakers is totally anonymous. We have the titles and the description that the speaker submitted and just based on that title and description you can vote on all the ones you're interested in. So I think we have over a hundred. So just go in and upvote all the ones that you have interest in and then based on those results I see what the highest voted ones are and put together a program based on what you're struggling with to ensure that we have the most relevant, high quality content for you to help accelerate your automation testing efforts in the new year. So vote now to do it. All you need to do is head on over to test guild.com vote. That's test guild.com vote. Hope to see you at Automation Guild 2023. The Test Guild Automation Podcast is sponsored by the fantastic FOL at Source Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

All right. Hi everyone.

Thank you for joining us. I'm here with Test Guild founder and podcast host Joe Cannotino and test automation architect, creator of Classy JS Larry Goddard. Low code, no code, lots of code, very little code. Guys, let's talk about that. Welcome everyone. It's not a new concept, low code and no code, right? We've seen it before, the guys who are old like us in business components and those kind of testing. But what is it, right? Is it something we should be talking about? Are we just wasting our time today and why should we? So kick it off and just tell us a little bit about your view on what it is and is it worth talking about, Right, Larry?

It's something like I say something I've been going on for a real while now. You know, the whole no code, low code, record and playback and all kind of, and all kind of stuff. It's been something we've been living with for years now. And I think now, now is a really good time to have these little discussions especially with the whole AI Al intervention into the arena. So you know, that's how I look at it. You know, it's one of these component added on thing now you have it the whole low code, no code from a test automation point of view and you have it from a whole developer's point of view, you know, and that's where we need to look at. So specifically for me, I just look at it from an automation point of view because that's, you know, that's why I live inside this, inside this arena. So yeah, I think it's something definitely worth not just this discussion, but I think it's something that we should all be talking about especially from a, on a corporate level.

Yeah, I totally agree. Like Larry said, I've seen more and more of it just because you know, I speak to a lot of people on my podcast and someone mentioned there was a Gartner report or a Forrester report where they said I think 70% of all development is going to be done on a load code platform in, by 2025 and I speak with a lot of developers that use tools like Bubble IO. So if developers are using these low code, no code type of platforms then you would think that why would they then do code based testing to create their tests for it. So based on what kind of applications someone's developing, you know, as more and more people go cloud Native, they're using more like SaaS based, like SAP, Oracle type applications. Those are all no code, low code. So I think there's a place in large enterprises where there's a lot of these applications that don't have testing. I think the reason why is a lot of testers on in that particular vertical or they have a lot of users there, like business users that don't necessarily have coding skills that allow them to automate this. And that's a big gap. So that's why I think we're seeing more and more of this low code, no code coming out. Because it seems like a lot of the no code, low code are all kind of. Most that I've been seeing are more towards like SAP, Oracle type applications, these prepackaged applications type of testing. I don't know if Larry's seen the same thing, but that's meanwhile I see them going after, but then obviously if those start taking root then I could see them going to handle a lot more of the more web based applications that we've traditionally seen with developer based tooling.

Yeah, Larry, No, I wanted to say. Yeah, absolutely right. And you've mentioned it as well. And I think Joe touched on a corporate strategy level. Maybe it is something more than just in the automation world, right? Yes. It accelerates things like Oracle and SAP, definitely. And we're seeing a lot more in the automation space as well, in the web based automation, mobile automation space where these things are coming in. But Larry, from you also a guy who created frameworks before and still actively doing so, right. Are we moving the code to a lower level or are we eliminating the code at all? So are we moving towards an easier way for information frameworks to operate as well?

Now I wouldn't say, I mean that's one of the general concept that a lot of people go away with that, you know, you do, we can remove all this coded frameworks out of the way and use all these low code, no code thing. But when you look at it from that, from that aspect now you have to ask yourself one question that pops into mind is okay, so we have these developers that are building things using low code, no code, but we have these testers now that is going to join that fray and start doing it that way. And one of the big issues I have, I personally have with that is when something go wrong, you know, when something go wrong because you don't have that knowledge, that whole knowledge of coding and everything, then where are we? And that, you know, that reminds me of back in the day with load Runner, with Loader. And it was a whole that, that's why the whole low code, no code thing with load Runner because it was a whole plug and play, drag and drop and stuff when you organize it. But when something go wrong it takes you more time to try and figure it out than it would have if you was actually coding literally coding yourself. And I think so. The whole point about it is it is good but I think it should remain added tool in accordance toolbox, if that makes any sense. You know, it should be an added tool in a coders toolbox because if you, if I say Joe here is this, you know it run it, it's no code easy, just drag, drop, pull and he does it. If it fails, he could go back and realize oh, that is why it failed. If I give that to somebody new in the world, they won't have the first clue where to start looking. Touch on the things dollar is it's good. There's still, I think there's still too much cons against it being becoming mainstream. Where we will be, where you would see real coders for this pretty conversation, real coders being sidelined for no code. Low code.

Yeah. I'm torn because you know, as you can see we're gray beards. So we have like a history with low code, no code solutions like Larry just mentioned, like be Windrunner, business process, quick test, professional. But I think technology has gotten better and it has advanced. So I don't know if I'm being prejudiced because I have a. I started off with those tools and I saw how, how they didn't really fulfill that promise. And I mean looking at tools 20, 25 years later and thinking they're the same thing, kind of thinking maybe they're probably not the same thing. Technology has gotten better. I understand Larry's concern. But also you know how much coding is actually coding nowadays and people are pulling in GitHub libraries and it's almost like they're doing low code now. It's little code based but it's more like a more English friendly kind of syntax nowadays. So what is low code? What is no code? You know, I think as time goes on it's going to become more and more the norm. And obviously I think a lot of these tools, like Larry said, if something fails, you want to be able to look at it. But I think over time they'll get better. You know, I've seen a lot of really fantastic technology that even runs a production and then just sniffs your traffic and then it can Generate tests based on real user interactions. And then I think the more. What's interesting is people kind of devalued manual testers. I know people hate that term, but a tester that didn't necessarily do a lot of coding, that had business knowledge. And so, and then they said, oh, you need to be a coder, you need to be a developer. And so people are learning all these crazy things about design patterns in Java, but then they're not a good coder or a good tester at that point or a good, you know, tester. So but now I think testers, when they come to these low code, no code getting more value because they can look at these things and say I know how the test should be and I don't have to worry about, you know, all this stuff that doesn't necessarily go into my domain as a tester. So pros and cons, I guess. I'd love to know what people think in the chat. So if you have any thoughts, let us know and I'll mention.

Exactly, John. And then, you know, we need to look at it also as, you know, what, where it started, where it's going and what is for. Because when you talk, if we come out of testing for a minute and we look at business processes. Yep, right. Business processes, local, no code is ideal, awesomely placed for that, you know, because of business processes. And you have like a pipeline, like you have a pipeline doing stuff so you check some code in and just automatically do something and something else take place. So it's for business process and it follows it all the way through, which is perfectly fine. And it's really productive in the sense that now all the like call them the business executives, all these people, they don't have a first knowledge of all these no code low code tools, especially no code ones where you just drag and drop something into place and it works. You know, all those are really, really good. But you know my. And again this is just like I say, my thing here is my low fears will end up running where, you know, where people started talking about, oh, they're bringing in automation robots to do stuff and then everybody manually going to lose the job. Right, right, exactly.

I don't think that's ever going to happen. Exactly. Yeah, yeah, you look at tools like, I don't know if I can mention tools here.

Yeah, absolutely.

Like I'm just using applitools as an example just because I've known them for years. I like their approach where visual validation, they're able to do things that you Couldn't do as a manual test or you couldn't do coding per se. It's looking at a screen, it's checking differences between visual things, things that are overlapping. But it takes a human to look at it to say, okay, it's bubbling this up as an issue is a real issue, but a human needs to go, yes, that's an issue. No, that's an issue. I think that's where we're heading. Not necessarily we're being replaced, but it's more like we're going to get these automated bubbled up insights and then you need to go in as a human with their brain and go, all right, is this doing what I think it's doing? Should it be? Is this correct? Is it not correct? So I don't know if we're going to get full blown, you know, everyone's being replaced. I just think all the skills we have are just going to be transferable to, you know, other areas as time goes on. Yes.

I mean, sorry, it's. But it's true especially. And like I say, like apitudes, you know, I've used them for a while as well and, you know, that's what it is now instead of you actually having to sit there and go through eight different viewports, you know, manually think, you know, you can just get up running like, like that. It is. You know, there's massive, massive improvement for over the years with technology. But like we will always say, I don't think we are ever reached to the point of, of we. Where human is not important in order as that brings to mind the whole autopilot things and planes.

Right, right. Yeah, right. Yeah. Well, how many pilots really fly a plane now? That's a good point. It's all autopilot. Maybe they just do it for landing and taking off and then they just do nothing during the whole flight.

Like I was saying the other day, could you imagine you board your plane and then you're here. Good morning, ladies and gentlemen. This is Larry Goody, your captain speaking. I'm working from home today.

That's true, that's true. Yeah.

Right.

But they need to be on board to look at the gauges and everything. But yeah, definitely. And be able to jump in if anything goes wrong. I think that's a really good analogy. But Larry, I'm just curious to know. You use webdriver IO and so someone could use selenium and create a framework from scratch. Well, they can use webdriver IO that does a lot of things for them automatically. So that to Me seems almost like a gateway to more low code solutions. Right. Because it handles a lot of the weights for you automatically. So I'm just curious to know what your thoughts are about that. Do you find WebDriver to be more of a heading towards that path or frameworks like that?

Yeah, I mean like I say, because I've been, I have experience one with both of them and two with the fact that I actually use in WebDriver as the like or the engine block for classic JS and you find either. So what I find is that things like IO, Cypress, just to name a few of the top of my head, that is the way to package it and the way to take, to take the existing technology and brings it into the modern era with everything, the modern art going on.

So where that is concerned, that's how I look at it. And for me they're doing good and I think that's the direction they're going in in terms of how to wrap things up and how to make things simpler for the user. And that in itself is a big plus. And in saying that, I look at this chat and I see somebody asking a question about enterprise tools and affordability.

Yeah.

And that is what. And just in saying that, yeah you have to answer that question is, is that yes or no to that question? The balance and trade off. Because with apitools you have, it's on a big scale and you have it. If you're a small organization, there are a lot of open source tools that you could use. So let's take classic JS for instance, which is my framework. I just use Node resemble js. What that does, that is the equivalent to what the whole apitools platform does. It checks, you know, it checks images against each other from very minute things to 1 for 1 pixel or 0.05 of a pixel to ensure that nothing then move on things. So there is a trade off, there's a balance. If you're small, there are open source tools that could do what you want. And then when you think about it, if you're a small organization, and I'm saying this lightly, so I hope apitus will bite my head off, you know, you don't, you really don't actually need to go for something, you know, that expensive and you know, in terms of affordability to that the same thing for things like Jira for once a better word. You know, there are little ones that you could use as a small organization. I mean if you sell it grow well then of course you look for the better tools to go with it.

Yeah, I think that answer is great. I agree with that.

Right.

And to bring it back to the local thing, I think it shifts where your skill set, you, your required skill set needs to be. Right. So again with your example Larry, you need more technical guys to implement these open source things and the same with, with the local thing, right? So if you are shifting the automation capability, let's call it that to a higher level and something goes wrong, you still need a lot of skills here, right. So we kind of transferring the skill set needed and the guys fixing the problems to a lower level, but it doesn't go away. And I think similar to this is the open source things does require different skill set and sometimes more advanced skill set to maintain and run and implement and look at the problems. And I think and that this is kind of the question around this leading up from this is so if we go low code and we have all these fancy solutions that anyone can run and anyone can automate, are we not just shifting the problem lower down or shifting the problem left and creating a bigger problem for the people having to implement and maintain and fix?

Well, I mean I'll take a shot at that I think, I don't think other thing is like that dramatic and you know, down the road because when you think about how people interact with things and how people coming in do things now if you come into the, let's say you knew you come in, you know, you can now go on online and you could go, let's say GitHub for instance and you could literally take down an entire working framework and with little intervention from you, it will work. You take it down, you follow the few instructions you have and it will work straight off. The only times you find and this is again the whole local thing and this is require what I would call low code for an attachment. If you put classic JS down, it's complete, it's all the folder structure is there, it's there, it's pull, everything is required. All you now need to do is be able to, let's say find elements on a page to do something and then two even that you don't even need to really worry about much like when I was doing it back in the day. Now you have a lot of tools out there that will do that for you. You know, a lot of plugin tools that you would use to do that for you. And so yeah, the local thing is like I say it's good. No argument on it is a real thing. But my only and that Carries me back to my original point on it is that I just personally find it's just nothing that somebody knew coming into the area. Should just take off the bat and run with and build a whole career around it. Let's say that for argument's sake, I think you should still look to develop yourself and you know, into what coding actually is. So, you know, you have both. You don't really use it much, but at least I have the idea. Like you say if something goes wrong, you know, you'll be able to help yourself without having to get on the phone and then pay somebody a lot of money to explain that to you.

Yeah, I think you need some literacy, coding literacy for sure to help you. But obviously I think, you know, every situation is different. Like you were saying, you know, there's enterprises, there's smaller companies like Lloyd Low Code Solution. You should do a proof of concept to see if it actually is going to do what you need it to do. Don't forget about working on your skills as well for coding. But I think as we get old, you know, it's, there's always a swing. Before I used to be like Windrunner, you know, record playback, qtp, keyword driven, don't need to code Selenium. All you need to be a developer. Now you're doing developer. You go to. I remember being a tester for a long time, then doing a job interview after a while and I'm like, what's going on? I'm on a whiteboard trying to talk about, you know, development things. I'm like, what, what, what is this? And so now I think it's swinging back to, you know, testers. And so I think it's a, like I said, you never know. You just need to kind of help your organization where they're at, use the right tools at the right time. And don't forget about, you know, you need to be fluent in coding because it is the language that we still all use for, for speaking with one another. But yeah, I guess it's a trade off.

Absolutely. Like, like I said, this is a concept business loves. Right. So for a business case, this is fantastic. All the pros are there from a business perspective now with my test add on and especially with my automation engineer on, is this something I should stress about? Right. And you said you still need coding, but is this. And Larry said, don't build a career on it. But if business gets excited and I'm on automation engineer sitting here, is this something I should be worried about? How does it affect my Life. Do I jump at this and say, well, and you mentioned that, Joe, I knowing how to code is fine, but I need to go down the street because this is what business was and this is the value or is it something that I need to step back a little bit as automation, you say, all right, I know about this technology, I know about where I can use it, but it's not necessarily the only thing for me. How does it. I think my question is more how does it affect me as automation engineer in organization at the moment and should I be worried?

I don't think you should be worried. I mean, like I said when I started my career in the 1990s, you know, oh, automation is going to replace testing or automation is going to go away eventually and it's going to be really automated. It's going to be a push a button, I'm still here, you know. So I think a lot of people have unnecessary fears and you always need to look out for your best interest though. Once again, I don't know if this is going off topic, but I worked for a large organization for 12 years and then I was laid off. And so if I just drank the Kool Aid and just did what they wanted me to do and only focus on their products, I'd have no skills. So you need a, the trade off is you need to help your organization but you need to also be aware of things that are out there and skills that are in demand and don't overlook that. So it's, you know.

Yeah, I mean adding to that, like you'll say, I think is when coming to the trade off and like I mentioned earlier, the whole idea is using it as money issue is what you do after the fact. You know, you have your work organization and they're sending you down a particular path because that's what that organization using it works for them. But what you have to do on the, on the other hand is you have to upskill yourself. You know, a lot of things come around, a lot of things change and you have to be aware and you need to, to be able to, you know, to know one, be aware that it's there. Two, you need to start pulling them for yourself on your own time doing what we call little POCs. And oh yeah, this is what this could do this and you just keep that in your heart because you may not work for that organization all your life, you may move tomorrow. And then when you reach tomorrow is a whole different concept. So the whole idea of it takes me for instance, I, you know, where I work, we use the classy JS as the underlying tool there. And the idea is, once things come out, what I tend to do, I look at what it is, I look at what you could do, I look at what the framework could do now and see, oh, would this be a good improvement? Or you know, what if we improve, if we pull this in, would it, you know, really work and things like that. So you had to keep yourself in that balance and you learn it, you keep it and you may not reuse it right away, but at least you have it. And just like Josie, if you just stay working for John Snooks Incorporated all the time, he wouldn't have no other skills than what you learned.

Learn that. Right.

And it's a good point. Like Larry said, you're also a leader. So it's not necessarily like I'm going to get my skills because if I get laid off, I'm going to have skill. It's also you could say, okay, I have skills to help them with other things, higher level things like, or be able to tell them, hey, this low code, no code thing, it's a great idea. But you know, here's the reasons why it's not going to work on this project or that project, or maybe it'll work here and not there. So giving your skills to help your current organization, but also making yourself better to help if you were to get laid off. So once again, the balance. But also as we go towards DevOps, it also can let you be more aware of other things to help your organization and say, okay, I can help you here, here and here. And then you probably can get promotions also because then you're not just focusing on, here's my position, I'm just going to focus on what they're telling me to do. Say hey, or what you tell me to do makes sense, but here's some issues with it and I've, I know about this other approach. Let's try that with this. You know, so it's also about leadership, right.

So what I'm hearing. So it's not necessary that low code is replacing any other solution. Right. What you guys are saying and what I'm hearing is that it's an arrow in the quiver that I can use when the business needs it. It's something that I'm aware of that we can use to solve a problem when, when a problem arises.

Right.

It's not necessarily one or the other.

Exactly. I mean that, you know, just to shift slightly, it also come, it also brings in the whole AI bit of it. And you have AI and you have frameworks on here, it's all integrated AI technology integrated in there. But is it good for. The question then comes, is that then good for an organization that does operate on a project basis or is it good for an organization where everything is in house? And just for argument's sake, and I mean like you have these consultancies that do work for other people, right? And if you're talking AI driven this on AI driven that, from what I said, that does make no sense inside an organization like that for a project where you start the project today and over six months period, it's done and it's delivered. Because with AI, it's all about continuous learning. Now if you look at Backlace, and I'll just call that off the top of my head, if you look at Backlace, you know, that's an organization that runs everything and said no, AI is good for them. Why? Because that will be running and that whole system running inside there constantly. So then things now becomes easier, slow and faster, sorry. And faster for them because it have a base in which to learn from. And that's why a lot of, I think people just lose, start to kind of lose focus a little bit. But when you hear, oh, local, no code AI ML, that is, that is forget that little idea of wait a minute, if you're doing AI, it need to have a whole learning process inside my environment before it could really add value to what we do in here. And you know, again, it's all about a trade off in what they're doing and how it affects where you are in whatever the project is at the time.

Larry just made me think, once again, this might be a tangent, but I think a lot of people look at other companies like Google or Facebook, that's what they do and they think, oh, I'm going to apply it to my current situation. It's like it doesn't make sense. Your organization could be totally different. So maybe they're doing some uber developer crazy stuff that may not even fit into your organization. But also what Larry said about AI machine learning, once again, I think people should try it. There are solutions like free ones, Helenium, which you could use in like Selenium to help you find locators and uses like kind of like a machine learning algorithm to be able to say if this element's not found, it can, you know, leverage what it learned to find that element so your test will run. So it's just like a give and take. Try things yourself. Don't just believe the hype, see where it can actually help you. And if it can't, then move on. If it can, then, you know, then do it. So don't fall in love with tools or an approach to AI Machine learning doesn't work for me. Or it's all, it's try it and see if it works with your situation. And if it does, great. If it doesn't, that's fine. It just depends on your situation, your organization and your group. I think it's very situational.

Absolutely. It brings you to something I always tell my guys is that AI is good, right? I agree that there's a place for AI, but remember, we as humans bring the I part to it. And don't forget the intelligence part of artificial intelligence. I think there's a big drive for us to move away and use these things to. Let's see if we can remove the, the human intelligence. But that's what we bring to the table in the testing part, right?

Did you make that up? I'm gonna use that the I in the AI.

Yeah, you can use it anytime. But, but, but as thesis, that's what we need to do. And it brings me to my next question around these local things, right? So if I can do low code, am I now automation engineer? Can I go to the market and say I'm automation engineer, I can do automation, right?

Yeah, you can. I mean I've been honest. Yes, you can. Yeah, you can. But then you do that. But then let's say I'm hiring, I am hiring to do something and the length of time that I have this project for is, is 3 months, 4 months, 5 months, 10 year time all depends. Like Joe has been saying constantly, it all depends on what it is need to be done at that particular point in time and how much time they're actually willing to give. Terry, because remember we still living in the age where a massive organization still thinks testing for a covered word tested is still a thing, you know, oh shocks. We need to test it before we send it out. You know, it's our leader. I mean massive organizations still operate like that. So yes, you can do it. And then it helps you as an engineer go there, you say you could do this. This is production is used. But then what my question here now becomes what about if the person you're going to work for don't use that, then what? You know, they have something in place already and you join in an existing team or something like that and all your knowledge and experience is in this particular area where does that leave you? So that just add to your other question, you know, where does that leave you then as an engineer with only this bit of it.

And I think once again it's not. I don't think we have to get away from one tool for everything. So I don't think you're going to have a situation where you're going to have a no code, low code solution that's going to help you with all your automation that you need to do within your software development lifecycle, regardless of what company you work for. So you may have that tool that you can apply to something, but there's going to be other tools or other things. You know, I think people shouldn't just focus in on functional automation as well. Automation should be applied to anything that can save your team time. And so it doesn't necessarily need to require low code and no code. And there may not have been a solution to help you with it performance or accessibility type, automated tests or a testing approach. So I think we need to not be afraid of tools and not think that a tool is going to replace us or you use one tool for all your situations. So people need to make sure that, you know, I don't think we'll ever get to that point. Maybe I'm wrong, maybe 20 years. But if that's the point, then we're all going to be out of jobs because, you know, if we think that way then everyone's going to be in the same boat. So what's the point of worrying?

Yeah, I mean, and that is true, you know, it's about, you know, it's getting it all together for your situation. You know, what is what's working for you, what works for that and not even just your situation, what works for that project at that point, you know, what works for that project at that point. Because in some instances it is easier, I shouldn't say the word easier. It is better and more economical to do manual testing on that project, to do automation. And that is something that a lot of people don't, they don't take into consideration as well. And automation in itself is to replace monotony, something that you're going to be doing over and over and over and over and over. You replace that with automation so you get done increased lightning time. You know, the whole thing about cross browser testing, you had to do it across seven browsers, different variation. Automation is awesome because if you do that manually it going to take a long time. Right. And that's what people need to remember. Although we have the no code, low code, coded, uncoded. All these nice things are coming along. We still have to think about is it really relevant to that particular project that we actually going to work on?

It's a good point. Another thing that comes to mind is when I started we had our own labs. So we had have different Windows machines three and nine point, you know what were all the different versions and you'd have to have a key to get into the room and have it set up with all the different browsers. So when all these browser based online services came on, did that replace me? Did that replace the situation? It didn't. So it's just like you said, it replaced the monotony, the things that you don't want to be having to focus on. You don't want to have to focus on maintaining your own lab when you have all these services that can handle it for you automatically. That doesn't necessarily replace you or make you obsolete. It just helps you focus in, like Larry said, on the important things, not the things that can be automated or things you shouldn't be focusing on.

Yeah, no, no, exactly. And I have to say this here because the community will be mad if I don't. We get that all testing is manual, right? So automation helps you to check things. And we get that. And we're not. When we say automation testing, we mean that the checking of the things.

You don't come out of tangent with this wording because I can't imagine going into an interview and they say did your manual test? And go what, what is that? There's no such thing as would you do on me? There's no such thing as that. You wouldn't get a job. But anyway, I'm not going to go off on that because I'll get into that. No, that's, I agree with you. Yes, totally.

But what I'm hearing and what is great to hear from this discussion, at least what you had to know, it's don't stress about it, right? Low code is good, no code is good, coded is good, AI is good, ML is good. Understand what it is, understand where to use it. Put that arrow in there and bring it out when you need it, right? So don't stress that the world's going to end for you. Understand that if your UAT cycles are long and business can contribute to that, you can use some of these solutions, right? You can make it available to them to speed up things, right? Understand what to use, where and when. There's no one answer for anything. And I think as A taster with my tasting add on. That's refreshing to hear. It's not panic, it's not run away, it's not find them to become a lawyer. It's become know that this tool is there, put that arrow there and when you come across a problem, know that there is a solution and this is the solution for it. Right?

Yeah, no, I mentioned that already. There's a lot of package based applications that a lot of critical businesses built on that I don't think testers are even aware of in their organizations. So your HR systems, your financial systems, that if they go down, your whole company is in trouble, but yet you don't even focus on them. And those are the types of applications that built with Oracle, SAP. They have tools that understand that flow, they understand it, they're in sync with all the release models that doing a code based approach does not make sense. So using like a no code solution that's made specifically for that would be perfect and actually would probably give you more work because you're focusing in on your teams and you can say to go to your business, well what are you doing for hr? And a lot of these things are probably not even tested. Say let's bring in a tool that actually focuses on this specifically. So you're focusing in on the right tool at the right place in your right organization. So it's not forcing a tool or a solution all across everything.

And that's the whole thing. It's all about not being siloed into one thing rule all, you know, this is what we use and that's what we will use and stuff like that. And one of the things is I always kind of say is that in choosing a tool on the, whether it's no code, low code, coded, it doesn't matter. Always choose a tool that the people in the organization that you're working with know how to use it not only does not want to use it could help you as the tester if you have issues. Yeah, so like you know, here I am, work for a company that they build everything using Java, just argument's sake. And then I'm QA and I bring in JavaScript and nobody knows JavaScript except me. What becomes when I get sick and leave and go for two weeks, you know what happens then is one of the. So my thing is if you're going to choose a tool, look at all the elements around you into, you know, who is on the team, what the skill level, app and everything. Because what you don't want to do is have Joe come on board. And Joyce, the QA engineer, and Joe village of panel. It's working awesome. And then Joe take a holiday and something happened and nobody, nobody company screwed until Joe come back. They have to be calling them on holiday. Hey, where you at, man? You need to get back here tomorrow.

You know, so just one of them things that.

Yeah, you want to be honest though, where your company is really at, because I guess it goes both ways. I worked for a company where they're like, all our developers use Java. They're going to help with the automation. And so you have testers learning Java and they have no idea how it's working. They're writing a framework in Java and it's awful when you know, if they use maybe Python and maybe they may have been better at using Python because ultimately the developers never helped anyway. So now you have developers not helping. You have testers that, that hate the Java, where they wouldn't be better off using the Python. So you have to be honest with yourself, with your organization. I mean, because what Larry says makes sense. But like in practice, like for large companies, I've seen like, you know, I don't know. But yeah, I agree with you.

Yeah.

Yeah, Nice. Is that. I mean, I think, Joe, I think you just put. I think you said the words better than I was trying to see them. That's the whole point as we get to that. Because a lot of times, and this in the reality is a lot of times you turn to a developer and ask him something and he just. Too busy. Yeah, the good old I'm too busy, you know, so working inside owner's sideways good and it has some weight. And then in other instances, it doesn't carry so much, you know, that makes. Bring me to a nice little point you make kind of outside the realm, but I think it still takes the whole thing. We're dealing with the people who, overseeing the QAs or testers or whatever thing, and we're talking about the. I like all of the QA managers, you know, these people up here about that, you know, dealing with people like that. You know, my. I have a question that lingers and I'll always like to ask it. How should they be in terms of coding? Whether the code, physical coding or the internal code, low code or anything? What should be a point where you say, all right, you know what, Joe, you could be the QA manager now because you have knowledge of X, Y, Z, blah, blah, blah. So now you could then help along with things. Joe, what's your take on that?

Yeah, you know, because it all depends for sure. But you know, you just made me think of another point. Sorry, it's kind of off what you just asked. But you know, when you said you developers, when you have the QA manager, you know, developers, a lot of times, like you said, you have to be honest with what your organization is doing. If you're using a low code, no code solution. That kind of takes me back to when I started when I used WinRunner QTP, a developer would never even touch it. So you know, even Selenium, when you use Selenium with Java, because that's what the developers are using, they didn't understand Selenium and Java, so even selecting the correct tool like Cypress would have been a better choice. So yeah, I guess it all depends on getting that QA manager on board and making sure they understand the real situation of what, what the, what what's happening and what you think will work best with the team. You.

Rachel, I just want to stay on this point. I know this is not got the point but we often choose our automation framework based on the technology that the developers are using, right?

Yep.

Yeah.

So are you saying, and this is not a low code question, but this is a question overall. Are you saying that there's some value in that at least so someone can help you, or are you saying that choose the tool that you are the best in and the people around you are the best in as automation technology?

I know you hate this answer, but it depends, right, Larry?

Yeah, I'm saying I'm not gonna say that.

It's one of those answers where anything I say is not the right, any answer. There's no right answer.

Yeah, but it all depends to be honest. I mean if you work in an organization where you have support, I mean it doesn't really matter what language you're in at the moment, but where you actually could get support, then it doesn't matter. But if you're working in an environment where support is hard to come by, then it matters. Then you need to do something that you could understand and you know how to and you will be able to help yourself and you know, make things go on if mistakes made. And then a thing that people doesn't pay attention to is your personal network and yet this is completely outside the realm. But it's your personal network. I'm there what I do, but at times I just get stuck and I have a little way to call it speed dial, you know, I'm sitting up, you know how and again and that's Something that people doesn't pay much attention to and that's something that they need to. Whether you're doing local, no code coded doesn't really mean you need your support in there too. Because even though, like you said, even if the organization, you can't get the help there, then you should have an avenue where you could get help. Now there's a lot of it, but you should still have at least one or two people in your Rolodex that you could actually call on. Because I need help, but I need it right away. And if you post it on a forum, it might take a couple hours before I get a response. So there's no right answer per se, but it just all depends on the actual situation.

Yeah, the perfect world, I think you would use the same tooling and you would use the same language and be kumbaya and everyone's on board. But you know, in reality, what I've seen, and it's usually at enterprises, usually when I see teams that say, oh, all our developers test and you know, everything's great. And if a test fails, everyone stops and fix it and ask, so how many people are in your team? They're like two or three. I'm like, okay, well that's why, I mean if you had an enterprise that was working for 8 to 10 sprint teams with 10 people on each team and it was just chaos. So it all depends on your situations. Very situational, very what they say, context. Context sensitive.

So where do we learn about these things? We've established it's great, it's something we need. The arrow that we need. Right, but where do we go find this arrow? Are there good places for testers to learn about low code and no code and their place in the world? Are they forums that we can use? Webinars, events that we can attend?

I'll push that one to Joe. Joe, this is. Now this is where. This is one of these things where, you know, it comes on to, you know how it works and where it is. Now I'm gonna what I do, but Joe is the expert.

But Larry mentioned community, so, you know, he obviously knows about community. He's in the uk. Everyone probably knows about like Ministry of Testing if you're in the uk. Great organization. They have test bashes, they have learning platform you can. They always have different types of challenges, like no automation challenges, low code challenges. That's a good place. Pitch my own thing. Test skill. Test skill. Com. I'm always blogging there. I do podcasts. I have a podcast on automation on Performance on security. So I think people, there's podcasts everywhere now. So there's podcasts you can go to, there's organizations like yours, obviously these type of communities, all these companies nowadays are doing these free online events. Sure, it's more like for Legion, they're trying to capture leads, but there are value there as well. I have an online event I run annually that's I've been doing since 2017 called Automation Guild. It's a five day event where we cover end to end automation, not just functional automation. So performance testing, security testing, anything to do with automation, we cover there. That's automationguild.com but yeah, I think there's so much out there now. When I started all there was was like a form mercury and that's where I got my information. There was also something called like sqa forum where everyone went to. So like nowadays, oh, there's all kinds of blogs, there's podcasts. You know, people like Larry speaks Everywhere, he's on LinkedIn. Like you said, build your community, build your Rolodex. Cause how great would it be to have Larry on your Rolodex? So if you had an issue with JavaScript, like, Hey, I know Larry, he actually has a framework that can help me. Just building that relationship is really important. Like Larry said, building up your, your Rolodex is probably your best place to start. But there's tons of communities out there that are popping up everywhere. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode, head on over to testguild.com a421 and while you're there, make sure to click on the Try for free today link under the exclusive sponsor section to learn all about Sauce Lab's awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the guild community. I'd love to hear from you. Head on over to test guild.info and.

Let'S make it happen, Sam.