 Welcome everyone to the self-healing test, the Holy Grail of Test Automation or just a lot of ado about nothing by Mathias Zaks. Now without further delay, over to you Mathias. Thank you very much. Thank you very much for the kind introduction. And yeah, thank you for having me here at Agilindia. It's a pleasure and the honor to be here. Today I want to talk a little bit about self-healing tests. Yeah, and self-healing test, this is a topic which has a lot to do with these buzzwords like machine learning, artificial intelligence, test automation. And these buzzwords are more or less present in each and every IT company. So this is kind of a really hot topic. And I come as an engineer and as an engineer, I always try to search for new solutions. So you could say I'm searching for the Holy Grail. I don't know if you know the movie Indiana Jones and The Last Crusade. If not, they're also searching for a Holy Grail and there are a lot of stumbling stones to come there. So quite tricky to get to the Holy Grail and also if you dare and you see that it's so beautiful. This doesn't mean that it's really valuable for you or that it works. And if self-healing test is the Holy Grail for Test Automation or just a lot of noise about nothing. Yeah, this I will clarify today. But first let me introduce myself a little bit that you know who is speaking. Yeah, I'm Matthias Taks. I am from Austria. So I'm living in Vienna and I am working for RBI. So RIPers and Punk International. They are as an agile engineering coach. This is not to do a lot with Grum or Kanban. It's more about the mature level of software development when we are training because with an agile transformation, we saw that we also have to increase or just work different with different technologies. And I personally focus myself in Test Automation. I am furthermore the organizer for the community of practice for Test Automation, which is an internal community where we foster Test Automation topics. You see, it's kind of my passion. And I also come as a developer by heart because this is kind of what I am. And now switch a little bit into the Test Automation area. Furthermore, I want to share what we are doing on conferences so that also you can benefit from that and also that we get feedback that we see if you're on the right track and doing cool things. And I also contribute to the paperwork. So I'm author for IT Megasins, which is also a nice experience for myself. Yeah, if you want to get in contact with me, please use the contact data preferable on LinkedIn. It's always nice to share and see and contribute. Good. Back to our great topic, self-healing test. So let me give you a little bit of agenda or the storyline of how I structured the talk. It's about first, I want to give you motivation why I focused on this topic. Why I have even investigated on it. Then I will share some numbers. So during my research, I found some cool numbers which fostered also my decision. And I want to share those of course. And then I will tell you what's the problem, what's the solution and what's my product I have chosen to tackle the problem. And then we have Q&A. We have enough time for that because this is important for me that we also that you have the possibility to ask. Good. Motivation. What motivated me why I have even investigated into the topic. First, I want to make a statement. This is software or test automation is software development. Hopefully everyone is in this opinion. If not, we can definitely have a great discussion afterwards in the Q&A. But for now, test automation is software development. This means it needs to be sustainable. It needs to be maintained. It needs to be refracted. It needs to get the same attention as business related code. This is very important. And maintenance especially, maybe you know or that this is, yeah, expensive, sometimes disgusting, annoying. And of course I want to decrease this maintenance effort. And if you get the test reports from the test execution from the test automation from the pipeline, maybe. And you have then you have some failing tests and you have to do that root cause analyzing. And this is very time consuming. And especially if you have done some patterns, you see, for example, my locator change and something like this. Then this is really annoying. And I was like, come on, there has to be a solution outside or why I have to do things. Same repeat myself. Yeah, because I'm really. Automate practitioner something like this. Yes, I really want to automate things where I see I repeated. And so I started to research. And here I found some numbers, some quite well known companies like Gardner and also Telerik. Telerik is a company they did a research on test automation back best practices and also maintenance and they published some numbers. And the first number I found which is maybe the most important one. It's got big 73.5% of all failing tests are caused of bright locators or a bad locator strategy. And this is a very huge number with a huge potential because this is exactly where our self feeling test is working against it. And I definitely want to decrease this number. The next two numbers are more related to automation. The first is 40% until we talk about this is kind of a trend in 2023. 40% of all teams or it teams will use some machine learning or even AI algorithms to get more agility to achieve more agility and scalability. So this is kind of a trend where we see a lot of things will get automated and also some touring will support us here. The next number is even much higher. It's 90% and this is really interesting. This is from Gardner. They say that 90% of all IT companies will have a dedicated job role called automation architect or automation engineer something like this. And then you have a reference number. Today it's about 20%. So this is a big trend there. My topic with self feeling test is really in the automation part of course and test automation. Gardner went even further. It is quite interesting. They invented a new term called hyper automation. What is hyper automation? In my words, hyper automation is the orchestration for the automation. So it's kind of you have an effective combination of a complementary set of tools to so at the end to achieve or to scale the automation. With tactical and also strategic goals. So it's kind of you orchestrate your automation because you have quite a lot of automation tools in place. And at some point in time you have to orchestrate it. And I did a Google trend research on that and you see some peaks in the past. Don't ask me what that this is. But since 2019 you see that there is a trend ongoing. People are searching for that. So this is a hyper automation is trendy. And self feeling test is has to do with hyper automation. So this is what we motivated me. So I wanted to decrease maintenance effort and doing the research. I saw that. Okay, this is a hot topic. So there must be a solution. But before I come to the solution, I want to share the problem and look at this picture. Look how old I look at that picture. And I was just kidding. That's not me, but maybe I look like that. If I again doing root cause analyzes and I find the exception with no such element. Yeah, so the problem what I tackling today is the no such element exception. What is this no such element exception? Maybe you know it, but still I want to explain it. It's a common exception in GUI testing. For example, if you use Selenium and the your automation scripts are not able to to get the element on the website. So it's not visible or it's you have some latency problems or the locator changed. And you know, I mean application changes after each release more or less. And in days where we release very, very fast, the application continuously changes and people change. And they can if you get new people into the team and you maybe have don't have very good common agreements or even that you kind of force it. Then they can change locators. They can invent new naming conventions. And if you have a very mature DevOps team, you can of course predict a lot that in the communication. But you know, sometimes the communication between testers and developers is not that well. Or even you use external software components like you have in your website. I don't know Facebook like buttons and something like this or other plugins. Those locators you don't have in your control and if they change, of course you have to do something. So this is exactly the problem. And for that I searched for the solution. And the solution is of course I spoiled it already on my title. It's self feeling. So self feeling tests. What is self feeling? What do I talk here? And overall you can say that self feeling is the automation for the test automation. So self feeling, there is running a process on your server in your test automation and it fetches data or grabs data. So additional data about the system, about the objects, about your website and stores it. And based on this data, it will learn. So this also means how more often you execute and run the stuff, the more data gets produced. And the better the learning algorithms can work and can then deliver you then solutions or self-healed locators in my area now. And at the end it's kind of a key to build an efficient test automation and test automation maintenance process. So this is very, very important. And this sounds really cool. So you know the problem now and the solution. And then I started of course researching about tools. And as you all know nowadays it's a tool mess outside. If you search for something you get so many tools and somehow it's really difficult to choose one. And so there are several commercial tools like from Marble, Test.IM or Crescentist. This is of course no product pitch here. It's just that you hear some numbers, some numbers from companies. And I as I called myself developer by heart like really like open source stuff. And I found one. And this is called Helinium. It's open source. And you can see here the GitHub link. Everything is published. And yeah, this is really cool. What is Helinium? Well, let me explain it. Helinium is open source as already mentioned. And it's based on Selenium and Java. So this is kind of also a precondition if you want to use it. And it's a real-time engine. What do I mean with that? This is really cool. It runs with your test execution. So nothing has to be installed on any server or something like this. The integration is done on the test automation suite. So it runs with it. It's a library. And of course it needs some infrastructure based on behind. I will explain you afterwards. It has this machine learning algorithm in place. So it consumes tons of data kind of and learns. Yeah, I have not investigated how the algorithm is designed. I also don't care to be honest. It has it in place. And for the developers, which is quite cool, they have an IntelliJ IDEA plugin, which is also easier than for the maintenance. If some healing is ongoing, that you see the results and then you can use them. The integration, how is the integration done? It's really easy. As I mentioned, nothing has to be installed on the server. Also on the test execution servers. The integration is done on the locators. So if you use locators like find buy or buy, I guess mostly common use locators, then you can use Selenium because the integration is done a level higher. So it's done on the web driver. And you can see it here. So in general, you have here your web driver, your Chrome driver. You also use a Chrome and then based on that, you can create the cell-filling driver. And then this driver you can use afterwards for your locators. So this is how the integration is done. Of course, you need some configuration files and so on where you tell the Helinium where the backend servers are and so on. But these are details. This is just what you have to prepare and as I mentioned, this property file. So this is what Helinium is about. Now I want to explain to you also how Helinium is designed from the components that it's really transparent because for me it took, I don't know, one or two hours to install everything. It was really cool, yeah? So what is Helinium? How is Helinium the components are? First, everything starts with test automation code. If you don't have the test automation code, you should maybe investigate the data and invest in test automation. It pays off. Here you have to integrate it with your Helinium client. So it's kind of the Helinium jar. So this is what you have to do. Then you have more or less everything done from this integration perspective. What you have to, of course, install is a Helinium backend. This is a REST for web service. And you can install it by your own or they have a docker support. So you can run it inside a docker, which is very convenient. So you just have to pull the docker image and run it. And of course, it needs a database. So this is kind of the Helinium Postgres database. See, everything is here also free. And this is also delivered by a docker image. So nothing intensive to configure. And for those who are really lazy like me, they also support or deliver a docker compose file. So you just have to download this Yammer file and start it. And both of these docker images get started. And you can interact with it through the REST for web service. So this is from that perspective, two things are missing. On the one side, as I mentioned, the IntelliJID plugin. Of course, you can download from the marketplace. It's integrated with the automation code. Yes, of course. And with the REST for web service. So this is from that perspective, but that's optional. And also for the reporting, they have a Gradle and a Maven plugin because they need to tell the backend when a new test execution is done or triggered that they can deliver a better report. But also that is optional. They don't have to use it. And yeah, so that's the component smallest. As I mentioned, everything very easy, straightforward and easy to use. Good. As next point, I want to, this is now kind of the most exciting one. I prepared an example that you really see various Helinium working, what do you get and so on. And here I prepared the example again with an open source project. Yeah. I guess you see a pattern. And this is a digital bank app also on GitHub. And I just prepared here a test case for the login. Good. So as I mentioned, this is our digital bank running. Yeah. It's a website. You can see here our test automation framework. You can see here, this is the Helinium backend. So very sophisticated now here. And this is defined by a locator. So you can see here, this is not with the password. And you can see here kind of the snippet of the HTML. You can see, oh yeah, that's the input. The ID is passed with that. So everything is fine. Good. Now you know, we have a pipeline. It's always executed. So it gets triggered. The test automation framework tries to find the element. And it has found the element. Cool. Everything is nice. But this status is quite difficult to read. Maybe the successful found gets also transported to the Helinium jar. And this gets also then forwarded to the Helinium backend. There it stores the additional data. So nice. Cool. So in your test execution, you see a green sign. Everything is fine. Good. Now, new version. New version comes. That's usual. And yeah, they implemented new naming conventions. If this is now realistic or not, we don't care. But the new name convention for the attribute ID. There was another HTML time. So password gets password input. Okay. Good. They, of course, deploy everything and the test gets executed. It tries to find the element. Yeah. And of course, what happens now? Boom. Exactly. No such element exception. But this is now in the locks. So you don't get that because Helinium is in place. And this status element not found or not such element gets forwarded again to the Helinium client. This gets forwarded to the backend. There the algorithm starts working. And it delivers new locators. Yeah. And these locators get then forwarded again to the test execution. And it tries to refine the element. You also can define refined counters and so on. How often you should try it. And it founds the element. Awesome. But why? Because it's not in the right box. Yeah. And if you go inside, you can see that it's first it in the red box, it first used the password one. Yeah. So this then it tries to heal. And you see it's used the heal locator now. With a score of 79 something. I don't know what that is. Yeah. Maybe this is the algorithm. Yeah. And it used the CSS selector input password. Yeah. So with ID again. So that's very interesting. Historical data. It also takes the data from the current run. Which is really nice. And of course an ID has a very high value. If I would remove the ID now, it would probably take the name. Yeah. Or I don't know. Most probably. And this is really cool. Yeah. So also if I locate the changes, it tries to take the new one. And yeah. Sorry. And the test screen. Yeah. So you don't see it. The test screen. You're just in the report. You would see that it healed it. But from the execution perspective, everything is fine. Good. Awesome. Two things are missing. As I already mentioned, report and again the ID plugin. First, the report. The report is available also from this rest for web server. But here you get delivered a GUI. And from each execution, you get then the healed report. And you can see here where nicely what was the failed locator. So you can see the password in the ID. And then also the healed one and a nice picture next to it. And also kind of a target where you can see if it's successful or not. I guess this is then that the algorithm learns from it a little bit better. The viewers can tell it that it didn't work. But I have not tested that one. Yes. Cool. From a recommendation from my perspective that this report is a little bit, it's nice, but I would integrate it into your current reporting, whatever you're using, maybe to also implement the new status. Yeah. Because generally you have the green ones and the red ones. Yeah. So the successful tests and then the failed ones. And I highly recommend to implement the search status kind of orange one where it's kind of the heat locators. Yeah. You can get this data out of this series. Server and that you see it. Yeah. Because it's quite nice to have this really. But also it's very nice to use it for a discussion with the developers that is telling it, hey, guys, or in the next grooming or in the rate or wherever you want. Yeah. Hey, guys, why we have 10 heat locators? Yeah. Why have changed them? Yeah. Because of course you want to, you want to use that also not only for the healing, but also as a discussion basement. And how does the IntelliJ plugin look like? This is like this. So you have your source code and you can do a right click on the locators. You have the healing results in the context menu. And if you click there, you have the or locators healed ones from that. So you can see the second one is this ID password input with the score 79. And the other one is, I don't know that one to be honest. Yeah. Good. So self-filling. What is self-filling? Self-filling is the automation for the test automation. Self-filling saves time in maintenance of the automation script. Self-filling. Source. Definitely there is no such element exception. And self-filling with open source means healing. And if you ask me now, is self-filling not this holy grail for test automation? Difficult question. Yeah. I would say, yeah. Yeah. It's the right way. I really like, I mean, you see that automation, hype automation, it's a high trend. It's a hot topic. And with Helinium, you don't have a huge border to get into that. Yeah. It's open source. You can really fast start it. Of course, if you're using Java and Helinium, and you can use it to get first experiences in this area. Yeah. I really like it. It's maybe not the holy grail. Yeah. But it's definitely one of the right steps into the right direction. I really enjoyed it. It was a really nice experience for my side. And yeah, that's what I can say to that. Thank you very much now for your attention. Hopefully it was interesting. Hopefully it was inspiring for you. And now you have time for questions. Good. There's one question. What if Helinium back end provided input conflict with another input field? Does Helinium back end database prepared or is it provided just jump rewards? Okay. The first question for conflict with another input field. I have never experienced that one, to be honest. All of my healings were always properly done. But I also have to say we don't have it now running one of our production products. It was a PUC, which we have done and we tested, I don't know, yeah, a lot of tests and all of them were really good. Of course, some of them, there was no healing. But for those where healing was possible, it really worked and there were no conflicts with others. I guess this, based on the data, the conflict is really rarely. But in theory, if I think about it, could be possible. But as I mentioned, up to now there was nothing. And the second one, does Helinium back end database prepared or it's just jump rewards? Who? I really don't know exactly the question. I mean, the database is in Postgres in Helinium. It's in Docker. Everything is really nice. You can also query it if you want to do your own researchers. So this is really easy to use. But I have not investigated. I just used it. Another question from Edina. Hello, Matthias. My question, is there any security aspect into this to be aware of? In my opinion, not. I mean, the data which is saved, so the server is in your responsibility. It's not somewhere in the cloud. I mean, you can, of course, it's a Docker container. You can run it wherever you want to. So about this data, you have to care about, of course. If you store it somewhere. But it's only about locators. So you don't store any data off the website itself. It's just about the HTML there. And so I don't see any security issues here. The next question. Does Helinium back and data, sorry, that point we had already, means do we need to prepare database? No, you don't need to prepare the database. Everything is done in this Docker image. So everything is set up. The database is initialized or the tables are created or permissions are set. The database user, everything is done for you. You don't have to do anything. What I did, I downloaded really the Docker Compose Yammerfile. And I just did Docker Compose run or up to come out now. And it provided me more or less an open port, which is a web server and it worked. So this is really, really easy. I really enjoyed that one. Another question. Do we have any self-filling test tool for unit test or cucumber test? Just curious to know. I really don't know. Sorry for that. I really focused here on the Selenium one. I also don't know how it could heal the error, you know, because which kind of tests. I mean, if it's a UI test, yes, but on unit test level, you probably don't test the UI, hopefully. And yeah, cucumber, it's just bit of the year. So sorry. Another question. So self-filling here is finding the missing element, right? So self-filling here is finding the missing element. Yeah, kind of the changed element, yes. I mean, this is, you know, I want to get quite nice feedback about this talk. It also was like this self-filling could be used to optimize the locators or and it's like, yeah, in theory, yes. So it's also that, I mean, in one side the application changed. You cannot find the element and it tries to find it differently. But if you have, for example, a very, very complex element and because of a latency, it cannot find the element. So it just, it takes too long and the algorithm is activated. It tries to refind it with a locator which is spread from helium and then it, in theory, could optimize your locators. So the tool itself has quite a potential and it's, of course, in a very early stage. There's quite a lot of ongoing. Meetup project. There's quite a lot of contribution and maybe to mention it's also available for for APU. So you can also use it for your mobile app testing. This I've totally forgot to mention. Sorry for that. So this is, you see it's, there is the tool is evolving. But at the end, self-filling kind of tries to find the missing or the changed element. Yeah. Thank you everyone for joining this session today. Yep. Thank you very much.