An Automation Journey with James Johnson and Nalin Parbhu

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Nayland and James all about their automation journey to codeless automation. Nayland is the founder of infused with over 20 years of experience in the software engineering, delivery and development. And James is the head of development and infuse for their use Mango testing application. So really cool technology and a lot of experience here, so you don't want to miss it to discover what tools and skills you're going to need for automation in 2022 and beyond because I think there's been a shift in the industry and that's something we're going to dive into, so definitely stick around. And speaking of automation in the new year, head on over to automationguild.com and register for the 6th annual online event dedicated 100% to helping you succeed with creating automation awesomeness. This event was created testers for testers. So you'll discover real world actionable tips, tools and techniques that will accelerate your career in the new year. Register now and sit back and enjoy the show.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Nayland and James, welcome to the Guild.

Hey Joe.

Hi.

Great to have you both. As I mentioned, you both have a lot of experience so this is going to be like a journey towards codeless automation. What you've been seeing in the field, how things have changed. So every journey begins with the beginning. So Nayland, I know in the pre show a while back we talked about your journey from using some other vendor tools and business process testing. So I'm just curious to know like where your journey began with automation before we get into where we are now and then where you see us going in the future.

Yeah.

So Joe, I mean my, my background. Software development. Right. So I've kind of always wanted to be a coder and I think in the, you know, when I started my career at the end of the 90s, no one planned to be a tester and I was no different. Right. So I didn't plan to be a tester. I accidentally fell into it and found a niche, you know, using my software development skills. So testing, embedded systems, coding, doing stuff that I like doing. And then I climbed, you know, the greasy pole of the test management ladder, right, and thought, well, it's all right, but actually I want to do automation. And that's kind of went right, if I'm not going to be able to find a career in this area, I'm going to develop a business in it. And that's how I started Infuse, really in this very building.

That's awesome. I love entrepreneurs in this space. So that's, that's awesome.

So yeah, so I started off in infuse 2002, Young, 29, thought, Right, let me start a consultancy business. I'll specialize in performance and automation. That's all I'm going to do. I'm not going to do any manual testing and I'll take on automation projects. And clearly I didn't have a clue of the commerciality of the business at the time. So when I said, yeah, I can come in and automate all your testing, everyone said to me, come back in, come back in two years, come back in three years, come back in nine months. And I was like, oh, this is not a good idea. But I stuck at it.

Right, awesome. So we're going to dive into that and know where the journey brought you into and some things you've seen in the industry. But before we do that as well. James, how did you get into, where did your journey start with automation?

Well, my journey started, this is my second career. My first career was in accounting and that was pretty well paid and you know, I had 15 years in that but I fell out of that and I re established a hobby of mine which was programming and managed to land a job with Enfuse, with Nanin. And that's where I first got involved with Used Mango and where. Well, in my private coding it had all been just test what I needed to test and until I'm happy with it. But obviously within a commercial business and with a public product, commercial product, then the need for decent diligent testing is obvious, is clear. And so my journey started really nine years ago when I joined Enfuse and it's been a long development of my testing experience and practices that we use internally and the tool that we deliver for our users. That whole thing has been a massive journey for all of us.

How did you become the head of development from accounting?

Well, I'd say the, the career change was a bit of a risky move and I think actually in The States, it's probably a bit easier. I think people are more willing to, to change careers over there. Over here we're a bit conservative. And so I was in between. I didn't really want to be an accountant anymore and I was just establishing myself. Oh actually. So what I actually did is I developed my own tool, my own software, which is an accounting tool. And that gave me a lot of experience but didn't really pay the bills. So when I applied to the role at Infuse, I was able to demonstrate quite a lot of skill, quite a lot of self taught experience, but not any commercial experience to that point.

So I always love entrepreneurs, as I mentioned in the testing space because they're creating something to scratch an itch and it's usually something they've been seeing in the field that's been bothering them or they think there's an issue with. So I'm just curious to know what have you seen most people struggling with that made you decide, hey, I think I could do a better way to come up with a solution to help them with all these other issues. So maybe we could come up with a few issues that you've been seeing.

Yeah, I think Joe, the few things that I saw in all my time in testing was there was a big need for testing as a sort of distinct piece of work. I always thought, you know, as a developer, that's not what you do, right. You know, you test while you're building. And so I was a big fan or proponent of quality engineering. Right. And I just recently threw out some, some old books I had from 2002 about now, how you should test early and you should collaborate and all that and all that. So. And so in my journey working in a career as an employee, I was often frustrated, flummoxed by the way that, you know, you do testing as a distinct phase and then, and actually you wouldn't consider automation till right at the end I'm like, why do you, why wouldn't you just automate right at the beginning? Just made no sense. You know, obviously I was in a world of my own right at that time. I get it. So why don't anyone else? And realizing that actually a lot of my peers don't, are not coders, they're not, they don't know how to code, they're not software engineers and they therefore test. Automation is complex. And that kind of led us to a few ideas around, coming around with frameworks. First of all, you come out with the idea of, oh yeah, let me come up with Some prepackaged tests. And then you go, actually, let me remove from prepackaged tests because actually once I put them on and I go through the customers customizations, I have to rebuild them anyway. Let's go through building a framework that will enable me to capture UI changes quite quickly. So move from that kind of idea of prepackaged tests to automated test framework, data driven frameworks, to having the idea of a scanner that worked on package applications. And that's what we settled on. But you know, the truth is that Joe, I can engineer, but I'm a much better person pitching out to the world than I am an engineer.

Right?

And James is a much better engineer than pitching out to the world, to clients. So I recognize the need for a product architect. It needed someone that, you know, could engross themselves in this area. And I was always distracted by, you know, okay, gotta go do that now. I gotta go see a client now I've got to pitch it and come back in it. So we saw the need for the product architect and someone that I could work with and the fact that James was, you know, fiscally competent, what made it, made it work for me because I could convey ideas and say, this is why I'm doing it. And I could talk to him about shareholder value or what I'm trying to do in terms of building value and he'd be like, okay, I get that.

Right.

And I didn't need to explain it. Sometimes that was useful. I had a person that understood that commercial. And then the other thing that I came across was, you know, and I don't think it's changed too much, but you know, there's a lot of record and replay type tools, right? And we came across sort of business process testing, which was by Mercury HP back in the time, which I, I thought that was the right way to build tests. You know, you going the way of components having modular, modular bits that you can reuse again and again. And you know, I used to call them testlets, bits of testing that you stitch together and, you know, move from testlets to components. And that's what we came up with using Mango's first version. And we stuck to that idea. There's always, it looks always seductive, isn't it? On a demo, right? You see a recording replay type of approach and it's done really quickly. But you know, ultimately when it comes to maintenance, it's the updating of the testlets, the sub process, the form, the element or the button that, that's always the challeng that breaks your script. And the thing that I realize is that especially in applications, testers know a lot. Testers know a lot. They know about all the rubbish that's going on with the requirements. They actually know who the rogue developers are. And so they know, you know, and actually know how to work around the rogue code as well. Right. And actually know the impact on the customer as well. So because they sit in the middle and they're the recipients of the software life cycle, they actually are very skilled human beings. They're just not coders. So if you can give them the ability to, to create automated tests, then there's something valuable that can be done. Right. And inevitably, you know, the James Johnson's and even Nalin Parbus on the world are not, not cheap, right, to enable those. I don't say democratize because that sounds a bit dramatic. Right? But you know, to bring test automation to the people that actually really understand testing. And they are two different skill sets. Right. And, and I know that James and I often debate, right, because, you know, sometimes we don't need testers. Right? I think you do need them. Right. Because they keep developers honest. So I think, I think of being able to bring automated testing to people who are really skilled at testing test analysis. They're able to analyze an application to be able to find defects, focus on that area and automate not just a regression, but actually being able to automate early at the outset rather than doing the tiny bit of regression right at the end is the bit that gave me an itch. That's kind of what we've been trying to do for about 10 years.

So, James, start off, I guess you developed an accounting piece of software. Is that what you realize? Oh, it'd be nice to have a tool for automation. That's how you got into automation. And along those lines, how do you take the requirements that nalan's given you and actually bake into the product? So, two part question.

Yeah, so that wasn't the way, I mean, I was in need of a job and Nan was in need of a developer. And so, you know, it wasn't. Testing wasn't a field or a discipline that I was really looking for. It's what I found. But the need for testing has just become such an integral part of how we work now. I have to say that obviously, because our whole business is built around testing. So we really ought to practice what we preach when we're developing our own tools, that we do test them thoroughly and correctly and using the best practice that we know of. So I think that it's taken quite a while for us to mature. But we've a strong need for automated testing because we need to compete, we need to deliver new features for customers, we need to deliver value in the product, which means we need to be able to release updates and improvements regularly, frequently that work, that do what we say they do. So we have used agile practices and agile practices really go hand in hand with automated testing. You really need to be able to test a lot because you've got frequent releases and you've got a lot of testing to do because each release requires testing. So along with the agile practices, we found that we've got to build a lot of automated tests. Now the thing is, when I first joined Infuse, I asked Nalin, he was telling me about this tool useMango, and I asked him, so does it test itself? And he said it didn't. And I thought that was a bit disappointing. So.

But there is testing that the irony.

Yeah, I know. So anyway, there's a principle of eating your own dog food in software development where if you can, you should be using the same product that you're giving to your customers. That way you get to feel their pain when you make a mess. So we do actually now use Mango for testing itself, and that's just one part of the automation that we do. I have deliberately tried to use quite a range of different tools over the years with our automated testing. So we've used Jasmine and we've used Cucumber and we've used WinAppDriver, we've used Selenium, we use quite a number of the different tools just to get a feel for what's out there, what other people are doing, what our customers may be experienced in. And we've come to the position where we have got large sets of tests, we've got tests for all different parts of our tooling. Actually, you may not know, but a testing tool is quite complicated and one of the problems with it is the terminology, because the word test just comes up everywhere. So when you're actually testing test, you have to run the test to know whether that test is a good one. So you have a test that builds a test, then you run the test and you look at the test results to decide what the result of the test is. So it's been quite a lot of confusion and quite a lot of long winded conversations that we have with ourselves with the word test appearing all the time. Anyway, we've on the need for automation, we've moved UserMango through quite a number of revolutions, really. We came across a problem early on when we were testing, which was that one developer would finish his bit of code and pass it on to somebody else to test it. And that other person might often say, well, it didn't work. And the developer's response was invariably, well, it works on my machine. And so that became a standard joke, really. We've had that ever since the early days that we say that to each other quite often. But no, what we do is we started with virtual machines, which we would use to set up a test environment that was independent of our developer machines, so that the test would be clean and it would give a true result based on what you would find when a user installs the system. And then over the years we have moved on from there. One year I went to the AWS Summit in London, one year, about four or five years ago, and that's where I first really understood the idea of being cloud native. And that has been a core principle that we've had since that time that we've moved towards that position of being cloud native. And that has really boosted our capacity to deploy and to test. Because the ability to deploy infrastructure automatically and then build your tools automatically, deploy them automatically, test them automatically, has been massively enhanced through that type of platform. So that's been a really amazing learning experience and it's really brought us huge, brought us forward hugely since the early days.

So that's a huge trend I've been seeing in 2022 is more and more companies are porting over to cloud native. So it's a good trend. We might dive into it later. But there's another trend I've been seeing and I think I have a reason for it is for some reason, but as Neyman mentioned, Cole, Low code solutions have been around for a while, you know, starting with the BPT and even before then people were using keyword type solutions. But it seems for me, the past year or so I've been getting hit up by multiple, multiple vendors, multiple tools doing codeless automation. So here's my theory. I found an article and funny enough, it's based in the UK on demand for it. Contractors have been the highest since March of 1998. And it went on to say the skills in short demand and short supply. And one of them was automation testing that they called out. So that is one reason why I think codeless automation is becoming more, more important. But I'm curious to get your opinion on what you think of why maybe codeless automation is really bubbled up now as a really hot topic, even though it's been around, it seems, for a bit. Nayland.

Yeah, I think I've seen sort of sub evolutions in the last two, three years around that sort of codeless automation. Joe. So the first thing that we saw is, I think a lot of manual testers saw the writing on the wall, right, and started writing selenium and frameworks. And yeah, they obviously got the good test automation dict and populated those words in their cv. You took them through a coding test and they'd flunk every coding test, right? And it was, it wasn't UK specific, you know, we hire here in India and it was just horrific, right? It was just, you know, 80% failure rate, very frustrating. And you're going, how am I going to make my financial numbers, which is predicated on human beings billing, right? So that was, you know, from the consulting side. So we saw that. And then also there was a period, you know, and I know that, you know, at a. Our sales, this person would say like two, three years ago, everyone's downloading, you know, a version of the robot framework or whatever, keyword framework, open source framework, and trying to do it themselves, right? They've all gone through that process now and of crash and burn. And now they've gone, right, okay. And now they've come back to. So for me, a person who's had a low code solution that could have fixed all this three years ago, you know, it's been very frustrating that the market has not quite grabbed it, but now the market is going for it, right? And it's been, and you're right, it's, it is. And I wrote a blog about it. Don't believe the hype, which is about, you know, a lot of people, you know, coming in saying, I got 4,000 automated testers back in Bangalore or Delhi or Noida or Bengal. It's nonsense, right? They've probably got about 40, right, that can properly code. And the truth is, is that without having a solid repeatable framework, which really only a product can provide, a lot of them struggle with it, right? And that's why a lot of these low code frame, a lot of these low code tools are coming about now because people have now, I think the market, the individual tester, the technical buyer, so to speak, is saying, I need the solution. And it's not, you know, £20,000 or whatever it is, or dollars or whatever. And so they're going at this, you know, that the price has become normal. We've always been normally priced. I would Say, by the way, but that's, but you know, the price has become, you know, it's not, it's not gone from many, many, many tens of thousands. For 10 licenses you need a hundred thousand dollars or pounds. You can get a low code or solution for your team problem, you know, sub $50,000. Right. And that's helped. So the price has come down. Technical buyers have recognized they need the help and ultimately in the enterprise, in those big heterogeneous systems where knowledge is in those testers heads, you're not going to get rid of them.

Right.

With automation because there's a lot of, lot of clever knowledge, you know, and we work on a complex telco project and you know, I know we have some clever estets, but the SMEs and the telco, what they know around OSS and BSS and how it hangs together and what can happen from phone all the way to bill. Some very smart knowledge. It may not be code, it may not be Python, but it's very smart knowledge about how this system's intricately linked together and where, you know, oh, there's an error here, there's an error here because of this, you know, file over here and this CDR is not working and I don't know what half the terms they're talking about, to be honest. Right. I'm like going, yeah, okay, all right, this is smart work. So I think for me the manual test is there to stay. The SD is a little bit too extricated from that SME knowledge and there's a place for this low code in there because you know that the SD is quite expensive and the company doesn't want to pay nine months for them to learn oss, BSS or whatever it is. There needs to be a different solution in place. So I think these low code solutions give these people with really strong technical business knowledge the ability to automate their testing and actually focus on interesting areas for themselves as well.

No, it's a great point. What I always think about is automation, the whole pipeline. So nowadays people are doing CICD and there's automation across the whole pipeline. You may have an SDA or developer that does a certain type of testing, but you have this whole pool of people that may have like a package application like SAP or Oracle. And like you said, they're, they're exper experts in there, but they may not be developers or automation engineers. And it's a no code solution that they're using to build the app. So why would they not use a no code solution? In that piece of the pipeline to do the automation. So I think a lot of people think, oh, we're going to go low code, everyone needs to do low code. But there may be pockets of knowledge you have where people can utilize no code low code and get a lot of benefits from it, but not saying everyone needs to use it. Do you think that's a good approach, James or Nayland for that? Have you been seeing that people went.

Through that sort of theoretical automation triangle and it's definitely valid. But you're right where you've got an SAP or a package applications, we do a lot of work in the higher education space. Student record systems that are integrated to finance systems or library systems or exam systems, those things are inevitably built. They're configurable apps, aren't they?

Really?

They're not. There's a misnomer that the people are called SAP developers or something like that, but they're not really developers, they're configuration specialists. Right. And for them, all those BAs or functional specialists, for them the low code solution is the right solution for those people and for people also who do a lot of their testing through the UI where there is no APIs to test or unit tests because you know they're getting a pre built application. Right.

So James, you mentioned that usemango has gone through a few iterations. I don't even think we told anyone what Use Mango is. So let's just a little what is Use Mango and how. I know buzzwords. Nayland said, sometimes there's a lot of hype out there, but you know, AI machine learning seems to be the buzz. So is that the reason why maybe low code no code is a little more reliable nowadays? Or as a developer is developing an application doing this, what are your thoughts on where we are now? Where we going towards the future of maybe making these things more reliable, maybe to actually fulfill the low code no code kind of vision?

Yeah, well, I think that the tooling at the moment, I don't see any particular people leading the pack or in terms of doing something different that's so special. I think that the quality of the user interface, the quality of the interaction of the user with the screen and the tooling that the test system provides to try to make the the job of the test builder easier. I think that's all improving gradually. I don't see any leaps and bounds at the moment. So the way I look at this is that an automated test is actually a program. So what you're really doing is you're trying to Get a non coder to write a program. And if you were a coder, you would think about subroutines, you would think about how to pass data around within the program and so on. That all comes naturally to a coder, to a non coder, maybe a test special or a business specialist, they don't have that frame of reference, they don't have that way of thinking naturally. So for what we're doing, we're trying to guide users down the path of perhaps creating a subroutine without really knowing it, or being able to parameterise a test or a subroutine in a way that is natural so that the language we use and the artifacts on the screen try to represent that in a completely non technical way. It's a big challenge. But I think that there's a lot of mileage in terms of, and making that really simple to use. And that's one of the things that we focus on in our tool, is the ease of use. I do think that machine learning will deliver quite a big change, and this is what I'm really looking forward to in the future is the specific thing I think machine learning can do is a vision based driver system. So just to explain that a little bit, I have this idea because I've been following the development of self driving cars for the last year or two and I found that to be absolutely fascinating. But what's really, really inspiring is the fact that through using vision, through using cameras on cars and machine learning models that are very complex in that case, but you can achieve a huge amount, you can do amazing feats of driving, which you would have thought only a couple of years ago that computers can't do that. So in terms of automated testing, I think that where we will get to is that we will have a visual driver, by which I mean the test system will be able to see by imaging. We'll be able to see what's on the screen and interpret it in the way that a user would interpret it. And that and that if we get there, which I think we will in the next few years, that will take away the need for the technical understanding of what is going on behind the screen, as it were. So for example, today anyone who's using Selenium webdriver will have needed to put to code identifiers into their program. So an identifier is the css or the XPath that enables the test to interact with one part of the screen. But that screen has already been built for a user to use. The screen contains information that a User can interpret by looking at it. So I think that what we really want to have is a testing system that uses the visual cues and can interact with the screen using those and that will become a much more natural way for a user to build their automated test that is driving a user interface.

Absolutely. I love that vision. I know a lot of companies are using visual validation and I see that definitely exploding for sure. Nalan, once again, back in the day we used to do image comparisons. I think like even winrunner had it where to identify an element you just say look at this image and it was always like pixel by pixel or I had to run it on one machine that I knew always worked in the same resolution. So what's your vision of the future since you're heading this? Do you come up to dreams of these crazy ideas or like how does this happen?

Yeah, I think ultimately our vision is really to make, to bring test automation and make it really simple. And we used to, you know, one of our tests used to be we used to have a functional expert. I won't name him but you know, he was an ex Navy man, right. He came out the Navy, joined our company. He was a functional expert in Oracle HR and knew everything to do with Oracle HR and we said if this chap could do it then it was good. Right? Right. So the final UAT test would always be right, let's get this chappie to build a test and you know, news from Liverpool would be oh, it's too hard, right? And go all right, it's too hard. We need to retry that. And I think ultimately for us the vision is really around. I still think the footprint of test automation is still quite low and if you go to complex projects it will remain quite low.

Right.

Because of the way part of that's because of integration and stuff like that. So I'd like to see, you know, use Mango crap of realizing that dream of being a self driving vehicle where we can automate tests really, really easily. Right. I think it needs to be a componentized and I think it needs to work heterogeneously across lots of applications without the need for different types of plugins. Working on, on that technical set and getting rid of that, that sort of, that layer of technical complexity will enable self healing tests to become real. Right. Because at the moment they're self healing kind of. Right. Everyone uses self healing but they're kind of self healing, right? The self healing, if you've coded it in, they're not really self he.

Right. With the visual Driver there will be. That's the thing. The visual driver means that the. Even if the UI has changed, it's been changed in order that a user can read it. And that's where that really will become really powerful because self healing will be. It's built into the technology.

So it's a good idea. You're talking about enterprise based automation where visual probably would help going across different like a mobile phone to a back end to a scanner, almost all these different things to get an end to end truly integrated test. You're saying vision AI type technology would help with that. Is that what you're trying to think of Nayland as well and James for that type of.

Yeah, I liken it to my 5 year old boy, right, Milan. So he's, you know, he can, he can look at an app on, on my phone and do the same thing on his iPad. And he's not an IT expert, right. And you know, he just knows that instinctively this is what I need to do. And ultimately that's what you want your test to do, right? Just to behave like that 5 year old kid going I know how to get on my kids program, I'm on Disney, I know how to get on my cartoon or I can get a blazing monster machines on the Amazon. I've done it. And you know, and I recognize those icons and so that's kind of where we're looking at kind of, you know, using that, you know, almost bringing that human edge to automation, right. And trying to drive it that way as opposed to looking at programmatically drive it because there's lots of commonalities on it, right. And building that. I think for us, that for us is really the panacea we want to get to because I think that then takes away the need for different tools on different technologies, right. I need this tool for SAP. I need this one for my old Java app and I need this, you know, if you go for example to. And we've got a great health system by the way. So I'm not here if you go to the hospital, the it is a bit cruddy, right. The doctors are awesome, but the it's. And I think it's probably across the world, right. You know, it's just a bit cruddy in hospitals. You got some of them have, you know, Windows machines that are, that you and I coded back in the 90s, right. So you can see this Visual Basic data gathering type app for patient record and then they've got a, you know, something that goes on a website, right? So they've got something that's a bit modern, that's digital and then they've got something that's really cruddy that they look at for X rays that, you know, does a big stored procedure, calls up information on this client. Right. And what you want is that flow to work across the board. Right, okay, how do I get a patient and register them and pull up their X ray, you know, and that's done by someone who can instinctively see in the screen, obviously with a bit of medical knowledge as well. So they know what to look for. Obviously they can't diagnose the X ray. But you know, using that, using that process that makes it instinctive and human edge in terms of automation. Because I think I see the market, everyone's kind of doing this record and replay 3.0 type thing. 4.0. I don't know where we aren't recording replay. I think we've done 2.0. We're probably a 3.4.0, but I genuinely don't see anything different. Right. They say, oh yeah, this one works because it's self healing kind of. Yeah. So but you know, it works on simple business processes, it doesn't work on complex business processes. If I want to check in, I don't know, vaccines from the factory. Right. And I want to run through lots of tests. Will it be able to run that kind of scenario? It won't. The visual driver that I like James, is talking about, that's kind of what we expect to do. We have to do complex scenarios because you will be able to run it instinctively as a user would be able to interpret instructions from the screen. And I think that's ultimately what we want to get to in terms of, from an automation tool. Once you crack that nut, then you can sort of really genuinely bring the benefits of robotic process automation. Right. Because there's that link between the two coming through like, and there's always been that test automation could be used for rpa. I think with something that's instinctive, then you can genuinely bring RPA benefits to business as well as operational benefits. That's where I would like us kind of be is that test tool that creates these assets that you go to the business and say, oh, by the way, you, you use this for operational benefit as well.

All right, guys, so we talked a lot about usemango and Fuse. So I guess maybe if people want to get their hands on this, a little more information maybe on what is use Mango, what they can do. Is there a trial version? How could Someone see how easy it is to use no code, low code solution. Any thoughts around that?

Yeah, we've got a very easy signup process for trials. Joe usemango.co.uk so you know, you can go on there, you can register in 5 minutes, you can download the software, right? It's, it's dead easy to get going and if you don't even want to talk to us, well, we won't talk to you. So you know, you can just sign up and trial it straight away or you can have an assisted trial as well. We've got a lovely backup team as well in the background to support people through the trial.

Awesome. Okay guys, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing coalest type of efforts and what's the best way to find or contact you? So let's start with you at Nayland.

Yeah, well I'm easily contactable, right. So I'm on LinkedIn. I'm Nalin Parbu Parbhu. I have googled and I believe I'm still the only one in the world. So that's really useful And I think with my surname there's only need three other people so for that spelling. So, so yes, so that's how easily I'm contactable. And I'm also, you know, if you go to infuse.it I'm on the website as well. Somewhere down the bottom there's a LinkedIn click to me. But yeah, so, so yeah, I should be easily traceable. Unfortunately I can't disappear. James Johnson, on the other hand, he has, he has a bit more advantage.

Do you have any actual advice as well for people to get started maybe with cordless?

Yeah, I think, look, I think in terms of actionable advice for me is really, it's about looking at the need for automation. There's nothing good process, right? So there's, I've been speaking to quite a lot of peers in the industry around the kind of state of software testing and they talk about, you know, lots of new tools coming up. Ultimately I think when you go through and you look at, you know, you want to go through automation, you got to go through the due process of why you want automation and what's the actual real benefit for it. And you know, and I think that part of what I call the discovery is standard test automation stuff, right? You know, what's the technology, what's your requirements? Choose your technology based on those requirements, right, and run POCs and do a.

Benefit case and James actionable advice and best way to contact you. I'll learn more about you.

Okay, my actionable advice is this. I recommend that you automate the simple things first. Don't give up because you can't do the hard things. You can get a long way with making a lot of tests that just do the basics. Get all your regression stuff done and keep working away at the harder things because they can take years to really crack. And I can be found. I'm James Johnson at Infused and working at Infuse.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a377 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. 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.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.