Automation in Production using RPA with Sune Engsig

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 speaking with soon Engsig, a senior evangelist at leapworks, all about RPA and automation while having to write code and probably a bunch of other automation topics. Sun has more than 20 years of experience with business and process development as well as IT architecture for enterprise companies. He has extensive knowledge and experience as a project manager in the public sector and telecommunications. He's also inspired by finding new ways to help companies expand their business with the help of technology. And I think RPA is part of that technology that you can hear all about today. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. They're 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.

Hey soon. Welcome to the Guild.

Hey Joe. Hey Joe. Thanks for having me.

Awesome. Great to have you on the show. Really, it's a hot topic. It's one of the areas I said was going to grow in 2020, which is RPA. But before we get into it, is there anything I missed in your intro that you'd like to share with the guild?

No. Spot on. No, really good. So yeah, really thrilled. And the part with, you know, figuring out together with, you know, in my previous employment together, you know, within the organization, but now also with our clients, you know, how can we make things work even smoother, you know, more perfectly, more efficiently? And I think the core, you know, the core of that is automation. So that resonates very well. So no happy.

Awesome. Very good. So I guess before we even get into it then is a lot of people, like I said, this kind of seems like a buzzword for people when they hear rpa. How do you define what is rpa?

Well, leapwork is we come from the test side of things, from the QA side of things. So for us, for me, RPA is automation in production. So the big difference here, of course, is that when you talk automation, you need to be sort of fairly clear on if you do stuff in tests or if you do stuff in automation. But then having said that, it's the same thing when it comes down to it really what we're talking about, if you're triggering an application to do, but everything is surrounded by the core, which is that we move data around, right? So we're shifting data, information requests, whatever it is, we're shifting that from one location to the other as part of an automation process. And that really is the core edit, irrespectively it's QA or it's in production or as we call that, rpa. So also if you go to our website, you'll see that sort of clear division between the topics that we discuss. When you're working it from a testing perspective, it has to do, of course, with verify and validate, given functionalities are there when you're running your automation processes in production, assuming of course, that this functionality is where it has to be. So you will not include those kind of activities within your automation flows necessarily, because obviously it will make the flow more complex, less resilient potentially. So those are some of the differences between, for me, at least, between test automation and rpa.

Nice. So what do you mean by in production? What kind of automation would you actually be doing in production that would be appropriate?

Well, everything really. So if you think of it looking at the organizations, right, so you have people working at desktops in front of their computers and driving business processes. So if you're working in HR are, if you're working in some sort of E commerce function or really any function within an organization where you have some degree of processes to it, then you'll be able to identify some of these processes which will be, you know, trivial, monotonous, repetitious. It could be, you know, creating a customer or create a lead or create a quote or create an order. You know, these things will be the same deal over and over and over again. So they are very well suited for automation to certainly from a starting point of obviously you can expand from there once you've got the knack of it. So there really is no limitation in terms of if you got a good process, you know what it does, you have a good control of it, you have control of the quality of the process. I mean, if you have a, if you have a process that you're executing manually and it's not performing very well and you automate that process, then you'll still have a process that's not performing very well. It's just going to be automated. So you'll have probably more pains coming out of it because it's now going to be able to do things much faster than a similar analog or manual one. So it's very important to differentiate between, you know, the quality of the process that have is it working good? And if it is, then, you know, most likely it's suitable for automation.

Nice. So I guess it's fair to say then, then is all automation testing rpa, but not all RPA is automation testing.

Well, I'm glad that you start out with asking, you know, what does it mean for me, because I can definitely see, you know, looking, looking throughout the market space that RPA is used quite frequently also when talking about QA related activity. So I am by no means a sort of a religious man in that context. So if people need to and would like to say rp, RPA also for testing, you know, that's fine with me. The core of it, both for test and production, of course, is that you have these robotic process automation tasks. They have slightly different purposes if it's running in test or if it's in production, of course, and they will be designed differently. You will have different requirements surrounding them when running in test versus production. So that's why for me, it makes sense to have that division between test and production when looking at these automation tasks, because you simply have different things that you need to be aware of. You have different things you need to incorporate into automation. As an example, if you have a business process automated in your production environments and you're executing, you know, create orders times 1,000, right? So you're running this thing a thousand times and you know, task number 583 fails for whatever reason, obviously you need to be made aware of that. There's a client waiting in the other end. So you have a higher degree of urgency, if you will, for those types of mishaps in execution as you would potentially have in testing. You would probably never do these thousand iterations in testing because once you've verified that this particular task is, you know, successfully running after, you know, the first or the second iteration, then you're happy. So just to give you some ideas of what the differences are.

So would you consider this an RPA then? User cases? Back in the day, I used to work for an insurance company and we, we had insurers that had to, they had a rate against different states with different policy sizes. So I created an automated script that populates an insurance policy with thousand vehicles and then all the different states. And then the insurer would go in and they would just test that the rating was correct based on that state. So is that what it does? It puts an application, it could be used to Put an application in certain state and then someone can manually interact with it without doing all the setup work that's required. That takes a lot of time consuming effort.

Exactly, exactly. It's a very good example. And actually we have clients both in health insurance and other type of insurance verticals doing just that, having this very complex landscape. So in the case of the United States, having these individual states where you'd have things driving, you know, also in the business rule level, which would affect, you know, how does that policy appear when it's fully processed and validate such things. That's the perfect candidate for automation in a test context. Because the alternative would be, you know, having potentially a lot of people, you know, just painstakingly working themselves through ultimately the same process, but then culminating these slight variations from state to state. And of course, needless to say, that's where this error propensity comes into play, which is one of our core messages. Right. So once you have these repetitious tasks, they're, they're monotonous, then you sort of have error built into them. Right. That's the way that the human, human mind works. If things get boring, they will, you know, you'll skip steps, you will forget to do stuff, you will pick the wrong data to enter or whatever it is, which of course ultimately will cause problems further down the road. So I think it's a very, it's a brilliant use case for test automation and obviously also a brilliant use case in automation because if you need to create these policies and you are in a market with 15 or so states, then obviously you also need to accommodate for this because then you will have to be able to create these quotes and offers on a daily basis. And again, if you don't have people to do it, then, sorry, if you're only relying on people to do it, then it's going to be longer run to do it.

Absolutely. And I assume since this is like you said, for production, it could be used for production based automation, that you're dealing with more than just browsers. So is rpa, does leapwork use Selenium under the covers for the browser piece? What technology does it work with?

I guess the question, yeah, good question. And yeah, as you say, process automation in real companies is not just running exclusively in a browser or exclusively in a given application. When you look at your normal average organization out there of a certain size, you know, it'll be perfectly normal for them to have in excess of 100 or 150 systems running within their infrastructure to accommodate for all the business processes. And more often than not you'll find that these business processes obviously will not accommodate themselves nicely within one of those systems. They'll tend to jump back and forth between these systems. So of course from an automation perspective you need to be able to accommodate all of these things. And what leapwork does is that it figures out sort of on behalf of you as a non technical user. Right. So you'll have no way of telling if obviously you'll know if it runs in a browser but, but if working with a desktop application. So something running on the Windows desktop, is this built using java or is it.net or is it a third thing? You'll have no idea. So that's what we sort of do on behalf of you. You don't need to worry about those things. You just focus on the steps that you want to take from the process. But getting to the answer on your question, stuff running in the browser, we attach ourselves to Selenium to do that. So we will be operating the browser in the same way your average Selenium script would difference is that we have these pre configured actions in the system. So if you want to click something, if you want to find something or type and then we'll convert those standard actions, which of course is something that your business user can relate to. Now I need to click on a button and now I need to set a dropdown or type stuff into something. So these business actions we're converting those things into in the case of the browser of course into Selenium instructions. So we sort of firing them real time at the browser driver. So if it's Chrome or Firefox or whatever. So from a user's perspective just choose which browser it is that you want to use and, and you know, put in these boxes, these building blocks as we call them that will say okay, now I'm clicking something, now I'm typing and so for and so forth and so expanding on that. If we move into the application space then we will start the application and then we will sort of have a little sniff and see if this is Java or if this is.net or if this third technology SAP. And then you know, we will make the required arrangements, so to speak, under the hood again. So from a user's perspective, again just focus on now I need to click stuff, I need to type, I need to set a drop down or whatever it is that they need to do. In that in mind.

Oh, so that's interesting. I just want to, want to get some clarification there. So Say someone's working in a flow and they have to deal with an SAP type application. Do they have to know that like, do they have to go to like an SAP section within the tool and then find the right function, like as you said under the covers, is it able to say, okay, you're clicking on this, we know it's not a browser, we know it's SAP, so therefore you don't have to worry about all the technology that you may be dealing with.

Yeah, that's the core principle. And now that you mentioned SAP specifically, we will actually, we're currently working on reinventing the way that do SAP. So you're probably going to be seeing shortly within Leapworks speaking now that we are here in March 2020, you're probably going to be seeing some specific locks coming to SAP because SAP is just, you know, SAP but working with your average desktop application. So there's a fairly wide range of stuff there. Right. Then we will do the math for you. You don't need to worry about it. Our current implementation of SAP does that same thing, but we just feel that also knowing the SAP users a little better than we used to, they kind of tend to prefer these things. So. And it's easier for us to accommodate that. You can talk very specifically on, you know, I know this, call this or whatever it is. So we try to accommodate what the users are doing and the best possible arrangement for them. So. So the rule of thumb is you have these default actions and we will figure out for you if it's technology xyz with the possible exception of SAP.

Nice. And a lot of times when I stick with vendors that have RPA type solutions, they always promote codeless automation. And I actually saw a demo by Alan Richardson, the evil tester on YouTube and he showed this product, your product, and it seemed like it's very. I forgot what you call it. It's like visual coding where we call.

It a visual language.

That's what it is. Okay.

Yeah, exactly, yeah.

So can you explain a little bit what the visual language is like? Can you explain like what it would feel like for someone that's listening to create a flow with your tool?

Well, the visual language is basically our mission is to try and see if we can some way bridge that gap that we sort of see skills wise when you look at obviously again we're coming from test, but it's really the same problem in RPA in production context. So what we see is that we have this great majority of people who has, you know, deep, deep, comprehensive insights of the business processes. They know the business rules, they understand fully how these are being supported by the IT business applications. So how are we enforcing and supporting our business with this batch of applications that we've set into motion to support this given business process? They have all of that nailed, right? So if you were to release a new version of these applications, you'd call these guys and they'd be able to write, put the thumb exactly on the sore spot and figure out, okay, oh, they didn't fix it yet, or we could still do better here. They just be able to do that for you very quickly. The ideal scenario would be, you know, when you talk about automation, you'd be able to talk to these people and say, please, could you automate this? Because you know all that we need to know, you know where to automate. Unfortunately, the automation agenda so far has been very much focused on how to automate. So how do I click a button? How do I type stuff into here, how do I select this field? Which, of course is a completely different discussion. And it's a discussion driven entirely by it or developers, really, because, you know, it's coming a tradition based on scripts, right? I write little pieces of code to do these things. And, you know, there's nothing wrong with that, to be clear. It's just to say that where we're coming from, we're seeing this problem with having these people over here who knows really what we need to do, but they don't know how to do it. And up until now, they've been effectively restricted from contributing to this hugely important discussion of driving quality and efficiency and what have. So the visual language is our attempt to make it possible for these people by showing them activities and actions that they can relate to. So from a business user's perspective, yeah, okay, I need to click this button now and then I need to put stuff into here. I need to set the value in this field. I need to do a selection in this grid or whatever it is, so they know what they need to do. So what we want to do is create these generic actions that will make it easier for them to do it. And configuring those building blocks is visual. So you point at the thing on the screen that you want to work with. If I want to click on a button, I point to it, and I have a building block that says, hey, I want to click something. And then you visually point on the thing that you want to click on, and then the building block will take care of the rest. That's the very executive summary of how the visual language works. What comes out of this visual way of working with it is a visual depiction which for all intents and purposes looks exact the same way as a business process. And this is something again that these users, these business users can relate to. They work with business processes every single day on whiteboards, on very long broad sheets printed out on a plot or somewhere or whatever it is. This is a term and a way of expressing an activity from A to B in a business process kind of way. This is something that they can relate to. So this is the visual language in leapwork. It's, it tries to describe the actions that you need to do in a business process in particularly in that way. And then we will make automation come out of that. So that's our angle to no code using this visual language which speaks on the terms of the business user and drive automation actions out of that coming from, what would you do as a user? So it's a bit of a long story, I'm afraid, but it is one of the key differentiators I've seen from our perspective, because no code is a lot of things. I'm sure you will also agree, having looked with your experience, you know, checking out these different tools out there, it's a lot of different things when you talk about no code. But this is our approach to it, really focusing very, very diligently on the business users and what do they need in order to convert their knowledge into something that will support the entire automation agenda for the company and not just these specific tactical tasks that it's traditionally been attached to.

Nice. So I'll have in the show notes a link to that video where it actually shows how Alan created these tests. It's pretty, pretty slick. I know one thing that people struggle with being, you know, experienced automation engineers is they're making the test reliable. Is anything built into your framework that makes it so if business users are creating tests that there's built in under the COVID things that are taking care of maybe wait times or network latency that could occur so they don't have to worry about that type of issues.

The short answer to your question is yes, it's built in, but it's at the same time it's something that you need to configure and optimize for a given condition. I was just recently on a call with a client who said to me, look, I want to test how long time it takes to run this business process on my business locations in Argentina, in the US in Germany, in Asia, and So forth. And obviously it's the same flow, it's the same applications in all of these locations. But he wants to remote control it from his headquarters, right, which was in Europe. So needless to say, we're now, you know, we're way beyond the core scope of automation. We have network latency, we have connection quality and all sorts of things playing into it. So coming to the answer to your question, how do you then accommodate these huge differences in availability and performance of the application coming from factors which has nothing to do with, with the automation platform. And of course the answer is that you also are hinting at, you know, managing timing and these type of conditions. And in the leapwork context, these are configurations that you do if you go back to these individual building blocks that are doing these very specific things. It's kind of an atomic approach, if you will, and you can set these conditions per action you do in the flow. So you'll be able to accommodate, if you have a step in your automation flow, where you know, okay, this will take longer for me, this database transaction or this data call on my developer environment, it's going to run slower here than it runs in my pre production or indeed in production environment. So I need the same flow to work in both locations. So how can I accommodate for that? And of course you need to allow for the slowest performing part, so to speak, to complete. And if it works there, then it'll also work in the faster end. This is part of, when I talk to clients and we build flows, I say you have two parts of building a flow. There's part one which is building the functional side of things. So verifying that, that this flow is now doing and solving the job that needs to be solved. And then on the other hand, once you figure that one out, then on the other hand you need now to make sure that it does that every single time you run it. And this is, you know, if we were developers here, we would call this debugging. And in effect that's what you do. You run the flow over and over again, you figure out where do I need to optimize timing in that particular action, and so forth and so forth. And we have this visual approach to this as well. So when you work this problem in this context, you have have video recordings of the run available, you have detailed log material generated by leapwork itself so it will communicate with you on your terms as opposed to your traditional system logs, which will be hard to read for many people. So when you look at the video, you'll have this interactive connection between what can you see in the application and what's being done by the automation application. So you know exactly where are you in the application when stuff breaks? Okay, I need to go there to fix it. So figuring out where stuff is broke when you do debugging is very fast. Typically something finding an error or something not performing stable and you know, figuring out what it is, resolving it re running it is something that you typically do within 20 to 25 minutes and you're good to go again. So we typically say, if you have your normal average business flow here, how fast can I convert that into automation? And we typically say you can do that within a half or a full day, including the stabilization bit. So that's pretty fast in most cases to get over that.

When you have these flows, they're all developed, can you schedule flows to run like you can a normal, like in Jenkins or can you run it against like Source Labs or something like that?

Yep, absolutely. We actually integrate into Source Labs. So we have an opportunity to use Source Lab, of course, a great tool if you have, you know, the requirement to test, you know, multiple variations of browsers and operating systems, you know, there's nothing better than what they, these guys are doing. So it's a brilliant tool. So we offer you to use them. So if you have a broad Source Labs subscription, then you can, you know, just hook up and run your. Obviously these flows need to be browser based. Running Selenium in order to also run there. You just, you know, you know, just choose Source Labs as the environment to run the flow on. It'll, you know, it'll run from there. So we support that fully. It's a great dimension to accommodate for your wider range of opportunities that you, especially when we talk about compatibility and the types of tests related to that. So we support that. And obviously the other part of your question in terms of can we do this scheduled leapwork is built to accommodate and fit perfectly into your CICD and your DevOps context, which means that you need to have stuff that can run unattended. Leapwork needs to be able to run automation without you sitting there and hitting a play button manually. Right. So scheduling could be either, you know, having it to run by itself every day at 1am or it could be a type of schedule which is just waiting for Jenkins or Azure DevOps or similar to say, hey, please run this schedule now. I've deployed new code. So the short answer to your question, yes, you can schedule stuff in leapwork and you can create schedules that will Accommodate either your own timing patterns. So you just want to make sure the smoke test is running every morning at 7am to make sure that stuff is ready to for people to come into work. Or you can have the other scenario where you're as part of delivery pipeline. So here's somebody pushing out new code and then you know, want to automate the testing of that. Then leapwork will just stand by and wait for this given component to trigger the automation run unattended and seamlessly. And by the way, you know, crucial part of that as well of course is the other side of the story. So here's completed automation runs of X number of flows. I had a bug in one or two of them. So automatically of course also create the bug in relevant bug management system of choice be Jira or Bamboo or whatever it is. Then we can do that as well. So of course in the broader arch of fitting into this CICD DevOps context as well.

So I guess most days people assume things to be open source. I assume this is not open source. And if it's not open source, I think a lot of people worry because if it's meant for more people to use then they have to keep track of licensing and installing stuff on people's machines. Like how does this all work?

I guess the question that's absolutely true. So leapwork is a commercial piece of software. So yes, you will have those parts of operating this particular product. That's something that you need to keep track of from our perspective. Of course, you know you're going to get great value of investment coming out of the efficiency that you get from automation, which of course is the generic claim from automation tools. But then elaborating a bit on that, saying that well you can do this seamless, this no code based automation on business users terms towards not just given applications. So specifically web, which is typically, you know, when you'll find these, these cheap slash free tools, they will be potentially even quite good. But only on for instance the web browser or maybe even just specific browser or browsers like the most typical Chrome Firefox ones and ignoring the likes of IE which you know everyone hates, but it's still there. So that kind of thing. How can you accommodate and make sure that you'll fit into that broader range of stuff. Going back to the point I made, when you're talking about automation in a real company, you're not just looking at one application, you're looking at a lot. And they will be built on wide range of technologies. You may even have mainframe you know, running around in the background or other type of legacy stuff or stuff that runs exclusively on Citrix or similar. Can you then also automate that? And then of course the answer is yes you can. But obviously having such capabilities and such flexibility is something that at least we feel is worthy of a price tag. So that's the long answer to why we're not open source. And you know, we're constantly feeding new stuff into the product. It's a subscription based product, which means that during the subscription product we'll be throwing new features at you with regular intervals. And you know, we're really driven by this. So we just want to make this the coolest automation platform that we can possibly do. And you know, we focus on that so you don't have other things making noise in the picture like, you know, here's test management capabilities or here's a reporting stack which is not as great as Tableau or Power Bi. So we're going to allow you to integrate seamlessly into those things rather than trying to emulate what they are very good at. So now very focused on creating this truly exceptional automation experience and make that as worthwhile for you guys as possible. That's, that's what we here for.

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

Well, go to leapwork.com and reach out to us there. And here you can also get the free trial so it's fully functional, there's no restrictions to it. So you can just knock yourselves out and highly recommend that when you do that, use the guys that we have sitting in support. It'll pop up there on the screen in the browser and those will be genuine automation experts responding to your question call, not just, you know, some bot or something. So, so they will be engineers and they'll be able to give you, you know, not just fix that immediate problem, but they'll also be able to sort of guide you and say, ah, you could probably do this a little better if you did so. And so if I were to give a specific advice for anyone considering beginning automation, it is do not start with the tool. Now that may be a bad commercial for me, but the point here is to say, as I also said previously, if you have a process that's not running very well, it's not going to be running any better when you automate it, right? So spend some time analysis you know, use some, some analysis, figure out what works, what doesn't work. How can I optimize this particular process in the way that it has to accommodate my business needs within my organization? And when you have that, you know, well in control, you know, then start looking at Autumn automating it. If you automate stuff that's not working very well, it's going to keep on working. Not very well. It's just going to do it faster. It's going to drive more pain compared to when you did it manually. So, so that would be my key in my before you start automating, thank.

You sun for your RPA awesomeness. For link 700 value we covered in this episode, head on over to testguild.com a301 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 Source Labs awesome products and services. 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.

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.