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

[00:00:01] Joe Colantonio 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 Goddard, who is an automation architect and creator of the klassi-js Automation Framework, and also the folks from Inspired Testing hosted by Jehan, who is a consulting in Architect at Inspired Testing. I 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.

[00:00:39] 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 on what sessions you want to have at the 7th annual Automation Guild taking place February 6th to the 10th of 2023. So all Guild Conferences, if you don't know our attendee lead and we take a really democratic approach to find out what sessions you want or 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 speakers 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 100. So just go in up for all the ones that you have an 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 handed over to Testguild.com/vote. That's Testguild.com/vote. Hope to see you at Automation Guild 2023.

[00:01:58] The Test Guild Automation podcast is sponsored by the fantastic folks at SauceLabs. 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 testguildcom.kinsta.cloud/SauceLabs and click on the exclusive sponsor's section to try for free for 14 days. Check it out.

[00:02:28] Jehan Coetzee All right. Hi, everyone, and thank you for joining us. I'm here with Test Guild ___ Joe Colantonio and test automation architect creator of Klassi-JS Larry Goddard. Low code. No code. Lots of code. Very little code. 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 kinds of testing. But what is it? Is it something we should be talking about or are we just wasting our time today and why should be. 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?

[00:03:09] Larry Goddard Something like I say, it's something I've been going on for a little while now. The whole no code, low code record on playback, and all kinds of stuff. It's something we've been living with for years now. And I think now is a really good time to have these little discussions, especially with the whole A.I intervention into the arena. That's how I look at it, as one of these components added on thing now you have it the whole low-code no code from a test automation point are going to have it from all developer's point of view. 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 why I live in inside this arena. 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 corporate level.

[00:04:07] Joe Colantonio Yeah, I totally agree. Like Larry said, I've seen more and more of it just because I speak to a lot of people on my podcast and someone mentioned there was a Gartner report or Forrester Report, where they said it takes 70% of all development is going to be done on a load code platform by 2025. And I spoke 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 test for it? So based on what kind of applications someone's developing, as more and more people go cloud native, they're using more like SAS 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, well, they have a lot of users, they're like business users that don't necessarily have coding skills that allow them to automate those. And that's a big gap. So that's why I think we're seeing more and more of this low code new code coming out because it seems like a lot of the no code, low code all kind of most they've been seeing and more towards like SAP Oracle type applications is prepackaged applications type of testing. I don't know if Larry seeing the same thing but that's I mean where 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 what developer-based tooling.

[00:05:40] Larry Goddard Go ahead.

[00:05:45] Jehan Coetzee No, I want to say. Yeah, absolutely right. And you've mentioned it as well. And I think Joe, touched on it on a focus strategy level. Maybe it is something more than just an automation world right? Yes. It accelerates things like you said, Oracle and SAP, basically. And we're seeing a lot more automation space as well in the way based on automation level automation space with these things are coming in but later from you also a guy created frameworks before and but still actively doing so right-are we moving the code to another level or are we eliminating the code and also moving towards the easier way for automation frameworks to operate as well?

[00:06:29] Larry Goddard I wouldn't say I mean that's one of the general concern that a lot of people go away with that you do we can remove all this code in a framework outer way and use all this low code and no code thing. But when you look at it from that from _____ one question that pops into mind is okay, so we have these developers that building using low-code no code, but we have these testers nowadays going to join up free and start doing it that way. And one of the big issues I have, I personally have with others when something go wrong. When something goes wrong because you do have got knowledge of all knowledge of code in everything, then where are we? And that reminds me of back in the day with LoadRunner and with LoadRunner it was a hold. That's why we hold low-code no-code thing going with Loadrunner it was a whole plug and play and drag and drop and ___ organizer. But when something goes wrong, it takes you more time to try and figure it out than you will have if you actually coding literally coding yourself. And I think so the whole point about it, it is good. But I think it should remain an added tool in a coolest toolbox if that making sense. It should be an added tool in the coolest toolbox because if I said Joe, Here is this, it runs, it's no code, it's drag and drop. I mean does it. If it fails, he could go back and realize, Oh, that is why it failed. If I give it up to somebody new in the world, the one clue where to start looking to try many things. Coders are good. We are still I think there are still too much cons against that being become in mainstream where you would see real coders for this conversation, real coders being sidelined for low code no code.

[00:08:31] Joe Colantonio Yeah, I'm torn because, as you can see, with gray beards. So we have like a history with low-code no code us solutions like Larry just mentioned, like the WinRunner business process, quick test professional. But I think technology has gotten better and has advanced. So I don't know if I'm being prejudiced because I have, I started off with those tools and I saw how they didn't really fulfill that promise. And now we're looking at tools 20, 25 years later and thinking that the same thing. I'm kind of thinking maybe that's probably not the same thing. Technology has gotten better. I understand Larry's concern, but also, how much coding is actually coding nowadays? People are pulling in GitHub libraries and almost like it's almost like they're doing low-code now. It's little code base, but it's more like a more English-friendly kind of syntax nowadays. So what is low code? What is no code? 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. I've seen a lot of really fantastic technology that even runs production in just snips the traffic, and then it can generate tests based on real user interactions. And then I think the more what's interesting is people's kind of devalued manual testers. I know people hate that term, but a tester that didn't necessarily do a lot of coding, they 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 tester. So but now I think testers when they come to this 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 all this stuff that doesn't necessarily go into my domain as a tester. So the pros and cons, I guess. I love what people think in the chat. So if you have any thoughts let us know and I'll mention it.

[00:10:35] Larry Goddard Exactly, exactly. Joe. And then, we need to look at the browser in a world where it started, where it's going, and what it's for. Because when even we come out for a test in five minute and we look at business processes. Business processes low-code no code is ideal awesomely pleased for that because the business processes and you have like a pipeline. You're like, I have a pipeline doing stuff, so you check some code and I'm just automatically do something on something else takes place. For business process follows it only make sure we're just perfectly fine is really, really productive. And it turns up now on the local and the business executives, all these people they do have full knowledge of all these no code, low code tools, especially, low code one way, just drag and drop something in the place and it works. All those are really, really good. This is just like I said, my thing, my fear is we end up running where people started talking about, they bringing in automation robots that do stuff and then everybody manually, you're going to lose the jobs. Exactly.

[00:11:53] Joe Colantonio I don't think that's ever going to happen.

[00:11:55] Larry Goddard Exactly.

[00:11:56] Joe Colantonio Yeah. Yeah. You look at tools like I don't know if I can mention tools here.

[00:12:00] Jehan Coetzee Yeah, absolutely.

[00:12:01] Joe Colantonio 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 say. 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. It's 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? Is this correct? Is it not correct? So I don't know if we're going to get full-blown. Everyone's been replaced. I just think all the other skills we have are just going to be transferable to other areas as time goes on.

[00:12:51] Larry Goddard I mean, sorry, sorry if by is true, especially like I say, like Applitools, I've used them for a while as well. That's where it is. Now, instead of you actually having to sit down go to 8 different view ports in a manual thing. You can just get to run it like that. There is a massive, massive improvement for over the years with technology. But like we will always say, I don't think we have ever reached the point where human, that brings to mind the whole autopilot things and planes.

[00:13:30] Joe Colantonio Right, right. Yeah, right. Well, how many pilots do they fly a plane now, though? That's a good point. It's all autopilot and maybe they just do it for landing and take them off. And then they just done nothing the whole flight.

[00:13:42] Larry Goddard Like I was saying the other day, can you imagine you're boarding a plane and then you hear, good morning, ladies and gentlemen. This is Larry Goddard, Captain speaking. I'm looking for a bomb today.

[00:13:54] Joe Colantonio 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 curios to know, you use WebDriverIO. And so someone could use Selenium and create a framework from scratch where they can use WebDriverIO, 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 what your thoughts are about that. Do you find WebDriver to be more of a heading towards that path or frameworks like that?

[00:14:30] Larry Goddard Yeah. I mean I can say, because I have experienced one with both of them, and two when we found it. I actually use Webdriver as the engine block for Klassi-JS. While finding, things like IO, Cypress. So just to name a few off the top of my head that is the way to package it. The way to take existing technology and brings it into the modern era with everything the modern are going on. So where that was concerned, that's how I look at it. For me the doing good on and I think that's the direction we're going in terms of how to erupt 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 as chuckling. I see somebody answer that question about enterprise tools and affordability. Just in saying that, to answer that question is yes or no question because what Applitools have is a big scale and you have it if you are a small organization, there are a lot of open source tools that you can use. So that's the Klassi-JS instance which is my Framework. I just use node resembles JS. What that does that is the equivalent to what the whole Applitools platform does. It checks images against each other from very minor things for 1 pixel .05 of a pixel to ensure nothing more. There are trade-off and 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 small of a vibration. And I seeing this slightly not so Applitools would bite my head off, you really don't actually need to go for something that expensive in terms of affordability, the same thing for things like Jira but ones that are better word look the ones that you could use as a small organization. I mean, it is semi grow, well then of course, you look for the better tools to go with it.

[00:16:53] Jehan Coetzee Yeah, I think that answer is great. I agree with that. But I tend to bring it back to the low code thing. I think it shifts the way where your skill set, what skillset needs to be. So again, with your example, you need more technical guys to implement these open-source things and the same with the low code thing. So if you are shifting the automation capability just go with that to a high level and something goes wrong, you still need a lot of skills here. 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 some of that to this is the open sources does require a different skill set and then sometimes a more advanced skill set to maintain and run, implement, and look at the problems. And I think this is kind of the question around this leading up from this is if we go no code and we have all these fancy solutions that anyone can run or anyone could automate, all 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.

[00:18:02] Larry Goddard I mean, I think I started out. I don't think it's that dramatic and down the road because when you think about how people interact with things and how people are coming in, two things now, if you come in arena, let's say you knew you'd come in, you could now go on online, you could go, let's say GitHub, for instance, and you could literally take that entire working framework. With little intervention from you it could work. You follow a few instructions you have and it will work straight off. The only time the whole low code thing and this is will require what I would call low code from attachment. If you put Klassi-JS done, it's complete. It follows structure there, it pulls everything required. All you need to do is be able to, let's say, find elements on a page to do something, and then two even that you need me to really worry about much like when I was doing back in the day. There are other tools that will do that for you. You know a lot of plug in tools that you would use to do that for you. And so yeah, the low code thing is like I say, it's good no argument on this is a real thing. That challenge me back to my only point in it is that it just nothing that somebody knew coming into the area. So just kick off the back and run with and build a whole career around it for argument's sake, I think you should still look to develop yourself into what code in actual use. You have both you don't really use it much, but at least I have the idea like I say, if something goes wrong, you'll be able to help yourself with all ____ somebody. A lot of money to explain that to you.

[00:20:05] Joe Colantonio Yeah. I think you need some literacy coding literacy for sure to help you. But obviously, I think, every situation is different. Like you were saying there are enterprises, they're smaller companies like Lloyd. A 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 there's always a swing. Before I used to be like, WinRunner, record playback QTP keyword driven don't need a code. Selenium all you need to be a developer and now you're doing developer you go to. Now 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 development things. I'm like, What? What? What is this? And so now I think it's swinging back to the testers. And so I think 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 need to be fluent in coding because it is the language that we still all use for speaking to one another. But yeah, I guess it's a trade-off.

[00:21:18] Jehan Coetzee Absolutely. Like I said, this is a concept business, right? So for a business case, this is fantastic. All the pros all day from a business perspective. Now, with what they said on and especially with more automation engineer. This is something I should ___about that? And you said you still need coding. But is this. And Larry said, don't go to career on it. But if business case gets excited and I don't want the automation 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 mention that Joe, knowing how to code is fine, but I need to go down this route. This is what business what's. This is the value or is it something that I need to step back a little bit as automation? You are so right. I know about this, I know about this much, I know about where I can use it, but it's not necessarily the only thing for me. Why I think migration is more is how does it affect me as an automation engineer in an organization at the moment and should I be worried?

[00:22:18] Joe Colantonio I don't think we should be worried. I mean, like I said, when I started my career in the 1990s, 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. I think a lot of people have unnecessary fears and you always look out for your best interests. Once again, I don't know that that's gone off-topic, but I work 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 want me to do and only focus on their products, I'd have no skills. So you need to trade off is you need to help your organization, but you need 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.

[00:23:03] Larry Goddard Yeah. I mean, adding to that like you said, I think is when comming to the trade-off or I'm like I mentioned earlier, the whole idea is using it is not the issue is what you do. In a matter of fact, you have your group organization and it's something you down a particular path because that is what that organization use I work for them. But what you have to do on the other hand is you have to upskill yourself, oh, a lot of things come around, a lot of things change and you have to be aware and you need to be able to one, be aware of its there, two, you need to start pulling them for yourself on your own time doing what we call the POCs and try yeah, this is what this could do. This I mean, just keep that in your heart because you may not work for that organization all of your life. You may move tomorrow. And then when they reach tomorrow is a whole different concept. So the whole idea of so what it takes me, for instance, we uses the Klassi-JS 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 if we improve, if we pull this in, would it really work and things like that. So you have to keep yourself in that balance. You learn to keep it and you may not to reuse it right away, well, at least, have it, and just like Joe said, if you're still working, cut ___ inc all the time, you wouldn't have more skills. Learn that.

[00:24:42] Joe Colantonio 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 skills. 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 is a great idea. But here are 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 you 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, that 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 to tell me to do. Say, Hey, are you tell me to do make sense but here are some issues. But I know I've got this other approach let's try it out with this, so it's also about leadership.

[00:25:37] Jehan Coetzee Right. So what I'm hearing wrong. So it's not necessarily that Low-Code is replacing any other solution. Right. What you guys are saying. What I'm hearing is that, it's an error Recorder 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 the problem arises. Yes. This is not necessarily one or the other.

[00:26:02] Larry Goddard Yeah, exactly. I mean, that's a shift slightly, it also come, it also brings in the whole A.I and you have A.I and you have frameworks. It's all integrated A.I technology integration in there but is it good for the question then comes is 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 talking A.I driven this and A.I driven that. What you said that does makes more sense in some organizations like got a project where you start a project today. Well, in six month period is done on delivering. Because with A.I it's all about continuous learning. Now, if you look at Barclays, I know that's called out of the top of my head. If you look at Barclays, that's an organization that runs everything. A.I is good for them. WHY? because if that will be running and that whole system running inside it constantly. So then things now becomes easier and faster and faster for them because they have a base in which to learn from. And that's why I think that's why a lot of people lose kind of lose focus a little bit with what you hear all low-code no code, A.I.There is that little idea of wait a minute if every doing A.I, it need to have a whole learning process inside my environment before I could really add value to what we doing here. And again, is all about that trade-off and what you're doing and how it affects where you are in whatever the project everytime.

[00:27:51] Joe Colantonio Larry, just maybe once again, this might be a change, 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 A.I 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 is not found, it can leverage what to learn to just to find that element. So your test will run. 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 do it. So don't fall in love with tools or an approach saying, ahh! A.I Machine learning doesn't work for me at all. 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.

[00:29:02] Jehan Coetzee Absolutely. It bridge into something I always tell my guys is that A.I is good, right? I agree that basically, but remember, we as humans bring the I for it. And don't forget the intelligence part of artificial intelligence. I think it's a big drive for us to move away and use these things to say, let's see if we can remove human intelligence. But that's what we bring to the table that they see part right?

[00:29:27] Joe Colantonio Did you make that up? I might use that, the I in A.I.

[00:29:31] Jehan Coetzee I made it up. You could use it anytime. But it states that that's what we need to do. And it brings it to my next question around these low code things. So if I can do low code, am I now automation engineer. Can I go to market and say I'm an automation engineer, I can do automation, right?

[00:29:48] Larry Goddard Well, yeah, you can. I mean, to be honest yes, you can. You can. But when you do that but then let's say I'm hiring. I am hiring per role to do something. And the length of time that I have this project for is three months, four months, and five months. Then you're fine, It all depends like Joe, has been saying constantly, it all depends on what it is does need to be done at that particular point in time and how much time they're actually willing to give. Because remember, we still live in an age where a massive organization still thinks testing for cover testing is still a thing, we need to test before we set up out. I mean, massive organizations still operate like that. You can do it. And then, it helps you as an engineer, go there. You say you could do this. There's a product that is used. But my question again, though, becomes, what about every person are going to work for don't use that. Then what? They have something in place already and you join nonexistent team or something like that. And all your knowledge and experience is is it in this particular area? Where does that lead you? Sort of just out the order question, where does that leave you, as an engineer with only this bit of it?

[00:31:14] Joe Colantonio 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 no code, low code solutions that help you with all your automation that you need to do within your software development lifecycle regardless what company you work for. So you may have that tool that you can apply to something, but there are going to be other tools or other things. I think people shouldn't just focus on functional automation as well. Automation should be applied to anything that could save your team time. And so it doesn't necessarily need to require low-code no code. And that may not have been a solution to help you with a performance or accessibility type of automated test 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 that you use one tool for all your situation. So people need to make sure that, 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 our jobs. Because, if we think that way, then everyone will be in the same boat. So what's the point of worrying?

[00:32:21] Larry Goddard That is true. It's about, getting it all together your situation. What's working for you, what works of that? I'm not even just your situation of what work for that project at that point. What work for that project at that point, because in some instances, it is easier. I should say, What easier? It is better and more economical to do manual testing on that project to do automation and is something that a lot of people don't take into consideration as well and automation in itself is is to replace monotony something that they're going to be doing over and over and over and over and over. You clears out with automation. It getting done increase length in time, the whole thing about cross browser custom we had to do it across certain browsers, different variation. Automation is awesome. Going to do that manually, you're going to take a long time and people need to remember, although we have the no code low code, coded, uncoded, and all these nice things are coming along. We still have to think about is it really relevant for that particular project are we actually going to work on?

[00:33:42] Joe Colantonio It's a good point. Another thing that comes to mind is when I started, we had our own labs, so we had have one different windows, machines, three and nine point. We're all the different versions and you 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 to that replace the situation? It's in it. So it's just like you said, it replaced the monotony of the things that you don't want to be have to focus in on. You don't 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. And like Larry said, on the important things, not the things that can be automated are things you shouldn't be focusing on.

[00:34:28] Jehan Coetzee Yeah. Not, exactly. And I have to say this is the community will be mad if we get that all testing as manual. Automation helps you to check things and we get that and we're not when we say automation testing we mean that the checking all of the things you check.

[00:34:46] Joe Colantonio The amount of changes with this wording because I can't imagine going into interview and they say, did you do manual testing? What? what is that? What is that such thing? There's no such thing as that. You wouldn't get a job. But anyway, I'm not going to go off the next argument. That's what I agree with. I believe.

[00:35:03] Jehan Coetzee But what I'm hearing and what is great to hear from this discussion at least what you have to know. Don't stress about it right low code is good no code is good coded is good. A.I is good. ML is good. Understand what it is. Understand way to use it. Put that arrow in there and bring it out when you need it. So don't stress that the world going to end you. Understand that if your write key cycles along 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 the days of testing now that's refreshing to you. 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 they and when you come across the problem know that there is a solution and this is the solution for it, right?

[00:35:57] Joe Colantonio Yeah. I mentioned already, there are a lot of package-based applications, a lot of critical business is built on. 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 you don't even focus on them. And those are the types of applications that built with Oracle ASP. They have tools that understand that flow. They understand it. They're in sync with all the release models that are 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 go to your business. Well, what do you do for HR? And a lot of these things are probably not even tested. So let's bring in a tool that actually focuses on this specifically. So like, so you're focusing on the right tool at the right place in the right organization. So it's not forcing a tool or a solution all across everything.

[00:36:54] Larry Goddard Yeah. And that's the whole thing, it's all about not being siloed into one thing rule all. This is what we use and that's all we will use and stuff like that. And what I think is I was kind of say is that in choosing a tool, whether it's low code, no code, coded it doesn't matter. Always choose a tool that the people in the organization that they're working with know how they use it. Not only that's what they use it. It help you as the tester if you have issues. Here I worked for that company that built everything use in Java. Let's see and then I'm the QA and I bringing JavaScript and nobody knows JavaScript except me what becomes when I get sick and leave and go for two weeks what happens then? My thing is if you got to choose a tool look at all the elements are on you including who is on team? What is the skill level and everything because we have no one to do this. Joe, come on board and Joe is a QA engineer, and Joe built up balance looking awesome and then, Joe take a holiday and something happen and nobody, nobody the company screwed until Joe, come back after the holiday. Where you got man? You need to go back tomorrow. So it just let them think that yeah.

[00:38:28] Joe Colantonio Want to be honest, though, with your company is really at because I guess it goes both ways. I worked for a company with like all the 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 if they used maybe Python and they did it, they may have been better using Python because ultimately the developers never helped anyway. So now you have to help. It's not helping. You have testers that hate Java, but they would be better off using python. So you have to be honest with yourself where you organization I mean because well Larry says make sense but like in practice like for large companies I've seen like I don't know but yeah I agree with you. Yeah.

[00:39:11] Larry Goddard Yeah, I think Joe, I think you said he was better than I was trying to say then. Whole point as he go because a lot of times and is in the reality is a lot of times you tell developer and ask him something and he just too busy. I'm too busy. Working inside. All of the side is good and it has some weight and then in other instances it doesn't carry so much. That brings me to a nice little point you may also be run by. I think it still keeps the whole thing when dealing with the people who are overseeing the hearings or customers. Well, I'm talking about the QA managers, the always people up here, above there, billion people like. Well, I have a question that lingers and I'll always like to ask it. How should they be in terms of coded? What are the code physical code in order into no code, low code, or anything? What should be, how to say, What should be a point where you say, all right, you know what, Joe, you could be QA manager I know, because you have knowledge of X, Y and Z, blah, blah, blah. So you could then have help along with things. Joe, what do you think on that?

[00:40:35] Joe Colantonio Yeah, it all depends for sure. But just maybe think of another point. Sorry, it's kind off of what you just asked. But when you said you developers, when you have the QA manager, developers a lot of times. So like you said, you have to be honest with what your organization is doing. If you're using a low code, no code solution, it kind of takes me back to when I started, when I used WinRunner QTP. A developer would never even touch it. So even Selenium when you use Selenium with Java because that's what the developers are using, they didn't understand Selenium in Java. So even selecting a 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's happening and what you think will work best with the team.

[00:41:30] Jehan Coetzee I just want to say on this point, I know this is not the point, but we often choose our automation framework based on the technology that the developers are using right? So are you saying this is not a low code question, but it's a question overall? Are you saying that sometime you met at least so someone can help you? Or are you saying that choose the tool that you are based in and the people around you already base in as automation technology.

[00:41:59] Joe Colantonio I know you hate to answer, but it depends, right, Larry?

[00:42:01] Larry Goddard Yeah, I'm saying I'm not going to say that. It's one of those answers where there isn't anything else that any answer way that there's no right answer. 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 at the moment, but we actually could get support then it doesn't matter if you work 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 would be able to help yourself and make things quiet, mistakes made. And then I think that people don't pay attention to is your personal network. This is completely I'll say around it was your personal network. And though I do. But at times I just got stuck and I have also, I will call it speed dial. I'm stuck and that's something people don't pay much attention to. And that's something that they need to. Whether they are doing low-code, no code, coded. They need your support because inside the organization. You can't really have that. Then you should have either new way you could get them, nor does a lot of it. But you should still have at least one or two people in your __that you can actually call on. Because sometimes you need help, but you need it right a way. And we post on a forum. It might be a couple hours before you get a response, but yeah, so it's no right answer to say, but it just all depends on the actual situation.

[00:43:36] Joe Colantonio In a 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 in reality, what I've seen and it's usually at Enterprise is usually when I see teams, I say, oh, developers test and everything's great. And if a test fails, everyone stops and fix it. And I ask, So how many people are in your team? They're like, two or three now. 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 ten people on each team, and it was just chaos. So it all depends on your situation. Very situational, very well they say contexts sensitive.

[00:44:15] Jehan Coetzee So where do we learn about these things? We've established it's great. It's something we need. But I know that we need a but. Where do we go find this error? Are they good places to learn about low code and no code in the place in the world? All the forums that we can use, webinars, and events that we can attend.

[00:44:34] Larry Goddard Now, of course that one Joe. This is one of these things where you come to know how it works and where it is. Now, I'm going to. But Joe is the expert.

[00:44:49] Joe Colantonio Larry, you mentioned community. He obviously knows about community, his in the UK. I mean, everyone probably knows about like ministry of testing. If you're in the UK, a great organization, they have test bashes, they have a learning platform. They always have different types of challenges like no automation challenges, low code challenges. That's a good place to pitch my own thing. TestGuild Testguild.com. I'm always blogging there. I do podcast, I have a podcast on automation and performance, and security. There are podcasts everywhere now. So there are podcasts you can go to. There are organizations like yours, obviously, these type of communities, all these companies nowadays are doing these free online events. I'm sure it's more like the Legion trying to capture leads, but there are value there as well. I have an online event I run annually that 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 of performance testing, security testing, and anything to do with automation. We cover there. That's automationguild.com. But yeah, I think that there's so much out there now. When I started was like forum mercury and that's where I got my information. There was also something called a SQA Forum where everyone went to. So like nowadays there are all kinds of blogs, these podcasts. People like Larry speak everywhere. He's on LinkedIn, like he said, build your community, build your Rolodex, because 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 Rolodex is it's probably the best place to start, but there are tons of communities out there that are popping up everywhere.

[00:46:33] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguildcom.kinsta.cloud/a421 and while you're there make sure to click on the try it for free today link under the exclusive sponsor's section to learn all about SauceLab'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, 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.

[00:47:17] Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps, and automation professionals in the world, we'd love to have you join the FAM at 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 love to hear from you head on over to testguild.info And let's make it happen.