 So thanks everyone for joining in. This is a great pleasure to have Nara and with us today. And I've kind of given an introduction already, but I'll let him take over. It's great to have him back. And thanks Nara. Thank you very much, Naresh. Yeah, so it was about 2005 when all this started, like Naresh and other people in ThoughtWorks were all working on different open source tools. And ThoughtWorks was a great place, as I was saying, to actually have open source. And when I joined, I wanted to actually do something in open source. That was one of my aims. And it had been five years of my programming. I had done one startup fail startup before that. And I kind of like knew that I could build products, but I hadn't yet figured out how to get an audience for it. So this was a great platform for me. So when I joined ThoughtWorks, I thought, okay, let me do something here. And one of the first things that hit me glaringly was in our team, which was working on a particular web project. The test automation was taking a lot of time. And it was taking a lot of time because we were using a silk as the tool. I don't think there's anything wrong with the tool, but the overall thing was it was actually taking a lot of time to do it. It wasn't very great with browsers, especially I. And the other newer browsers, in fact. So we needed an alternative. So then I thought, okay, so far before that, I had worked on JavaScript parsers. I had worked on proxies, et cetera, as part of my previous project in another company. We had done a co-grossing product. And because of that knowledge, I thought, hey, I knew a lot about JavaScript at that time. It was the time of IE 4.0 something and then Netscape some early versions. So I knew the differences between how someone did document.id and the other one did document.all and the other one did not support that. I knew a lot of those things. So what I thought was let me actually look at Selenium and see if I can contribute to that. So that was the start of it. And when I looked at Selenium for our particular project, Selenium at that time was in frames. There would be a top frame and then underneath you would have your application opening. And the application that we were working on had a frame breaking code, which means that you do something like top.location is equal to self.location, which kind of blows up the frames and then opens yourself in the top window. Now, when that happens, the Selenium thing no longer works. So I thought, hey, this is a perfect place to put in the proxy and the JavaScript injection and make it work. So that was the start of Sahi. And we had some discussions with the Selenium folks. But given I was in India, they were in Chicago, and it wasn't so easy to collaborate. And there was an energy that was in me to actually go ahead and do it myself. So Sahi started like that. And it was used in a project that was fairly well received. Then it went up fairly well and on source forage. It went up to rank 26 in about 100,000 of projects. And then I kept working on it. But there were some things that were very different between Selenium and Sahi. So different that we took absolutely different paths. We did a lot of technical decisions which are different from Selenium. We took a lot of commercial decisions which were different from Selenium. And today when I look back, it is an interesting thing to see where we are both placed. So this talk is a little about how the whole thing happened. Now, let me just bring up a slide. This is the talk about the tale of two automation tools, Sahi Pro and Selenium. So it's not just Sahi Pro, it's the evolution of Sahi and Sahi Pro and then Selenium. So as I said, Sahi is an open source web test automation tool. It started out like that. It started in 2005. The principle mechanism of automation was to use a proxy to inject JavaScript into the browser. And the JavaScript had full access to the DOM. So we could actually navigate to the different elements and identify different elements. And then we would perform actions. Now, the actions were performed using JavaScript events. So JavaScript events had a good advantage that it was inside the browser. And if you actually did the simulation right for all the events, you could actually do a proper automation thing without needing the browser to be in focus. So that was one of the things that happened then. See, a lot of times the decisions that we make on what the technology should be for a particular solution is also dependent upon what you know at that particular point of time. So for me, I was good at Java. I was good at networking, proxies, etc. And I was good at JavaScript. So this kind of lent itself to taking a solution which was based on these things. So that is how the solution started off. And as it evolved, right? So from 2005 to 2009, I kept working on Sahi. So it was an open source project. I was pretty much the main contributor to it over the whole time. And I kept working on it as a part-time thing. So I had a forum that I had set up and people would ask questions there. I would respond to them. And I had a good reputation of being responsive to the end user. Eventually, in 2009, I shifted to a commercial version. So I'll talk about why we did that, etc. But so far, the timeline is something like this. In 2005, we launched Sahi. In the first version that we actually took out, it had a recorder. And it had automatic reporting and integration. So the first release itself, like we integrated with cruise control in our project and made it work with the continuous integration system. So around 2007, Ajax was picking up quite a bit. So we added automatic weights. The automatic weights, basically, the way we did it was to hook into the XHR HTTP request object. And listen for callbacks and basically put a wrapper over it and figure out when something starts and ends. And then based on it, go further with the next step. In around 2009, we introduced the concepts of near, under, etc. Near, left off, right off, etc. So the near was the first concept we actually introduced. Near is a pretty cool concept in which an element is identified with respect to something near it. Now, why was this actually important? One of the main problems of browser or any automation has been to identify elements in a way that it can be re-run every time. Now, user interfaces may have buttons which are, which buttons are elements which are meaningful by themselves, which could be that it's a button, like a login button. So you don't have too many of them. You'll have one or two login buttons. And most probably the first login button and the second login button are interchangeable so they don't have difference in functionalities. So there is no ambiguity in that. So you understand that both of them do the same thing. Now, the other thing that could be there is something that is repetitive. For example, a checkbox to select a list of emails. So if you have a list of emails and you have checkboxes near each one of them, the checkbox is like if you were to identify it by themselves, it doesn't have much meaning. The meaning comes in when you say that the checkbox is near this particular subject. So then it becomes meaningful. Now, the thing is the user interface, which is what we are trying to automate, the user interface is almost always unambiguous because if you actually have a confusing user interface, the end user will not be able to use it. So one of the things that happens with the user interfaces is that it comes out as something that almost every element is unambiguous or it performs the same function without any... It is not unique, it is the same as the other. So this premise is actually very useful when you're trying to automate or build an automation tool. So you say that, okay, is this element significant by itself or is it significant with respect to another? In just these two things, you can actually make everything automatable. So then like in around 2010, we added like regex-based identifiers, etc., where you identify something with just partial text. So if something was saying, hey, welcome, Naresh, you can just identify it as welcome and then figure out whether Naresh exists there or not. So the next few years, around 2009, 2010 is when I launched Sahipro. Why I did it is something that I'll talk about. But we launched Sahipro and over the next few years, we actually added a good editor, frameworks in it, much better reporting and other things and also keeping pace with HTML5-based developments. There was a lot going on at that time. Around 2017, we added Windows and Java application automation. So now we are actually going ahead beyond what we are talking about as Selenium versus A. So we went on to become not only just a browser-based automation tool, but also like do Windows automation, Java automation, mobile automation. So in 2018, we had mobile automation. In 2020, we added SAP automation. We added other features like auto-healing of scripts, intelligence suite analysis, optical character recognition and image-based identification, etc. So what happened over time was, you know, we realized that just having a browser-based solution solves the web part of it. But when we were actually selling as a commercial tool in enterprises, they had lots of interfaces that they wanted to work with. Now, when they were working with a lot of these... So we didn't want them to learn new things to actually be able to automate another technology. So as far as like we are concerned, it's a user interface is a user interface. You have like, and your inputs are basically the keyboard and the mouse or like, you know, sometimes when you're like swiping, okay? But apart from that, it's pretty much constant that, you know, you're going to enter text. You're going to do a few actions. And for that, like, we said that, you know, as an automation tool, everything else is the same. It's only the engine that needs to actually change between these technologies. And so we just built these engines for each one of these technologies to be able to automate all. And as an end tester, the experience would be the same. So they would have a recorder, they would have the same kind of like editor, etc. They can use like, you know, like the identifier and the objects by to identify different elements, use the same access to your object repository. It's pretty much the same thing except that like they will see a set mode windows or a set mode Java in between the scripts. That's that's all that changes to them. Of course, the identification mechanisms between these technologies are very different. And we get into the runtime of each one of these to figure out what is the best equivalent of a DOM to actually be able to traverse and find things. So the points of divergence between Sahi and Selenium. The first thing was the philosophy itself. And after that, like, you know, there were this object identification, event simulation, automatic weights, recorders, the importance given to coding itself. And then like some things about like, you know, whether the W3C standard web browser became a W3 standard. And our our take on like what it was to actually be open source versus commercial and come in community was a dedicated support. So philosophy itself, right? So we were very focused on testers. Okay, so from from the first day itself, the solution that I wanted for my team at that point was that we were like developers were doing a good job of like this is thought works remember like we wrote unit tests, we did a lot of like, you know, whatever tooling it needed to actually make our code as clean as possible. We were we were pair programming. So the developer efficiency in testing was in developing was pretty high. Okay, and also like, you know, the unit level testing and the deep dive testings, they were okay. But when it came to looking at it from from a higher level perspective of the domain of like, you know, being broad enough to look at the overall thing, developers are not that great at it. So this is as a developer, I know that when I actually am like working on a problem, I'm going deep down into that code into that particular line of thing to actually make it work. And when I'm working on that it is a unit level that I'm concerned concerned about not really, you know, the overall thing at that point I forget maybe like that is why it came up to that but like at that point I forget and I go deep and it is easy to get lost in the depth and a lot of times the problems happen in the depth and the depth for a long, long time, maybe two days, three days, like a week, two weeks. So the thing is you need somebody to step back at various points of time to say, hey, you know what, this like in the overall scheme is working, not working, this is what it should be, etc. And I feel that for me, like that is where testers add value to be able to, you know, course correct for us to be able to find things in the business domain that like we are unable to actually figure out. Now, oh, by the way, like this is something that I need to say that, you know, I'm and it is this, the reason I actually wrote a testing tool is to make the overall development life cycle faster. Okay. And it doesn't mean development life cycle only means developers, but basically everybody involved in software making should like be able to speed it up and make it as like frictionless as possible. So that is that is what like, you know, was the original idea behind doing this. And as a developer or like as a team member, right, I want things to do as fast as fast as possible. Now, when I look at when I looked at the best testers I knew in my career. Okay. I really appreciated people who would bring out, you know, some behavior or some like, you know, some bug, which is at the application level, which is at the business level that we hadn't thought about because developers are good at like, you know, finding and fixing and debugging and like small small things at the low level, but if something is broken for a business, like the testers need to bring it on and I have like immense respect for people like that. So to be able to enable them to do automation. So for us, like it was, you know, hey, automation is like super dumb. Okay. You already know what you need to do. It's only that, like, you know, instead of delegating it to a junior to actually keep doing it again and again, you just automate it and it'll nicely fit in into the overnight runs also. So like, you don't need to spend any time or effort in doing that. So that is the, that is the overall philosophy with which like we built the product. So for us, anything that actually eases the effort of the tester, like, you know, recorders, like automatic reporting, building of frameworks, these all we think of it as a tool problem as something that should be part of the test automation tool. So when a tester picks it up, we want the best testers who are business testers to be able to pick an automation tool and be able to run with it, like, from like, you know, day one. Now, how close are we to it? Like, we're pretty close, but the thing is that is that has been our aim. Now, this is fundamentally different from what like, you know, WebDriver wanted to become. So WebDriver wants to be a browser automation library. Right. So this is fundamentally, like, you know, what we aim to achieve out of these two things. Okay. So and for us, like, code is if it's like saying, okay, hey, you could write a program to do this mathematical calculation or you could use Excel to do that mathematical calculation. Now, I believe the Excel is the equivalent of, like, our automation tool. So, like, you don't need to write programs to do it. You need, like, something that will abstract out the problem and give it to you in, like, you know, a very easy way of doing it. So that's what, like, we are trying to do. So this, I don't know if you want to see it, but, like, it kind of is a testimonial that, you know, we had little or no experience with test automation. So it made it easier to get us started and we were able to see a success very quickly. So this, like, I put in just because, you know, not many people know of Sahi and when I'm talking about it, like, and given that it is not very popular, do you really believe what I'm saying? So this is just to actually not say that, hey, it is good, right? I'll leave these here. So, okay. The other thing that, like, we were, you know, okay, so, as a test automation tool, okay? So there are these higher level things of, you know, okay, frameworks, organization of tests, execution controllers, et cetera, reporting, et cetera. But at the core, like, we still need the engine that automates, okay? And the engine is supposed to do basically two or three things, okay? The first one is a reliable way of identifying elements, okay? The second one is to be able to simulate events. And the third one is, which is something like, you know, you may say it's part of the tool or not, but is waiting or waiting position for the right amount of time. So if you get these three things right, it's kind of like, you know, your automation engine is ready, okay? Now, here, right from the beginning, because, like, we were good at, like, JavaScript, I was, like, fairly decent at JavaScript. And I knew that, you know, when you, the DOM is a beautiful way of accessing different elements in the user interface. And the DOM gives you access to everything that is on the browser, okay? And so it was fairly trivial for me to actually build a library around the DOM and say that, okay, hey, identified by the text or identified by the ID, any significant attribute of a particular element. Now, right from the start, we didn't go with expats. At that time, like, CSS selectors were not even there, okay? So the reason we didn't go with expats was, I was fairly simple. I have written a lot of web applications, even by that time. And I knew that, like, the user interface changed a lot. The HTML structure changed a lot, okay? Now, when I have an automation tool that tests the functionality even after I change the HTML structure, can the test still run and tell me whether things are working correctly or not? That was one of the questions that, like, you know, the tool had to solve. Now, if we used expats, expats were basically, like, you know, a way of traversing a XML structure, okay? Now, the XML structure has, like, you know, an XSL, sorry, a definition, I forget what the name is. So you have these XML definitions also that you can actually verify it against. They have a fairly rigid format and you know how to traverse to each one of them in a specific way. And unless the version of that XML changes, like, XML changes, you're going to get to that, you will be able to use that expat correctly every time. But browsers and HTML is not XML. So while it looks like XML, but it is not XML. It is a very different way of it is a UI representation and it will change when your application changes. So using an expat, which is a rigid way of getting to a particular element, didn't look great to us. Now, there were two ways by which expats could be used. One is to actually have a full expat, which is, like, horrible, okay? So the next thing that people do is to actually send it, is to do it via a regular expression-based expat. Now, a regular expression-based expat is another added complexity. So there is a joke that goes on that, you know, hey, they wanted to actually build a solution and then they tried to do it with expats. Now they have two problems to actually solve. So it's the same. Sorry, with regexes. So regular expressions in expats is actually you may end up, like, actually targeting something else instead of, like, what you're targeting and it is not trivial to understand and when it is not trivial to understand the likelihood of you actually, you know, constantly maintaining it, changing it and, like, looking at it is less likely, okay? Now, so if not expats, what? Like, as I said, like, you know, we traverse the DOM and this is a question that had been asked before that, you know, hey, if not expats, like, how do you actually do it? Well, does a developer ever use an expat in his application in his JavaScript code? Never. Developers always use, you know, like, you know, the DOM-based way of accessing different elements and jQuery and all these tools are built as wrappers around the DOM to actually be able to access something much, much simpler. Now, we chose to write our own thing because this was also, in initial days people would say, hey, now I can just call the jQuery code to actually do automation, to identify elements. Two things were wrong with, like, using jQuery. One was jQuery always returned a collection, okay? So you always, like, were getting back multiple elements, okay? You don't need it. You only need the first element. The second thing is what if, like, the application itself had another version of jQuery that it was using? So we were injecting the JavaScript and, like, these jQuery versions would conflict. So we needed something which was our own, which didn't depend on anything else and would be able to, like, you know, solve to identify different elements. The third thing we actually look at is, you know, everything on the user interface, we don't look at it as how it is visible through the implementation or through the code. We look at it as how an end user sees the application. So, for example, in HTML, if you actually say, if you wanted to say, like, red, red ball, okay? You would say, if you put, like, red space baseball or, like, you know, a new line as in slash and ball or, like, you know, multiple spaces ball, it all is visible to the user and to the user as just red space ball. That's it. There is nothing, there's nothing more to it, like, as the end user sees it. So if you were to actually, you know, automate and identify this particular element, we would just use it as, like, you know, red ball, okay, red space ball. That's it. It doesn't matter how it is in the HTML itself. It doesn't matter, okay? So we normalize all white spaces. And this also happens across different browsers. And they treat it differently, actually. Now, we, we traverse through the frames and iframes automatically, okay? And even through shadow DOMs. Now, why do we do that? So, if, as an end user, if you look at a web application and you see a particular text field, now, you do not know as an end user whether it is in a frame and iframe or in a, or inside a shadow DOM element. All you know is there is a text box there, okay? So we want to keep this simple for the end user, right? So if you use our controller to actually identify an element, it will be, like, as simple as that. You will just be able to, able to identify it as what you see it, okay? And the third thing we had was, you know, the use of near in under, left off, right off, etc. So this is a very powerful concept, like especially, look at a tree structure, okay? You have these plus and minus icons near all these labels. Now, if you wanted to expand a particular folder, let's say, so you would just go to the plus icon near the folder and click on it. So it's a very powerful concept. Sometimes what happens is you have a grid and this grid is not really a HTML table. It could be something like, you know, it divs, actually, like, you know, put together as a grid. Now, you want something to the right of, so you want a delete button to the right of the username. So it should be very easy to say, give me, like, you know, underscore, button, delete, near this particular text. Now, this also means that a lot of, you know, if else conditions, for loops, etc. that you were writing before goes away. You have just one simple way of expressing this particular relation overall, okay? And also this can be done using the recorder by itself. So the recorder will show you how to actually do that. So you don't really need to think too much also as to what the relation is, how the relation should be picked, etc. So you just, like, you know, click the anchor on what you want and then, like, hover it. I may show it if I have time, but, like, let's say. And the other concept is, like, you know, of testability. So we hear this a lot, you know, developers are writing programs that are not testable at all. Now, these HTML interfaces, like, it was not testable. They don't have IDs, etc. For us, if you have to touch the code for making it a little more testable, then there is something fundamentally wrong about your automation tool. So for us, like, anything that is visible to the user interface and is, like, you know, accessible to the, visible in the user interface and accessible to the user is actually, like, you know, testable. So because of all these things that we have done, right, like, traversing the DOM, like, looking at different attributes of the element, using left of, right of, in under, etc. All these makes everything actually testable. Now, of course, there are these elements like canvas, etc., which are not. But the rest of the things you shouldn't really have to, you know, be adding IDs or, like, changing the code or the developers code to do any of that. So the tool should be able to do it. That's our philosophy, okay? So next comes the event simulation. So we used fairly, you know, because we were good at JavaScript and we understood how the whole thing worked. We built event simulation for each browser, okay? There are differences. There were a lot of differences. The differences have come down quite drastically now. Even now, there are differences. So basically what we do is, like, you know, we take an element, like, we attach hooks on all the callbacks and all the different, you know, event event, event handlers that can be possible. So for example, on click on most of the on mouse zone, etc. And then we we take a, we see what all is happening in what order, etc. And then we simulate the events in the same order. So this is what we do for all browsers and we have these automated scripts which tell us, like, whether we're doing it correctly or not, etc. So this works on all browsers mostly. So even when a new browser comes in or a Firefox variant comes in or, like, a new thing comes in, if the browser, if you're able to set the proxy on the browser, then most probably Sahi will work for it, okay? So that has been, that had been good for quite some time, okay? It's still good. And we kind of, like, where things couldn't be done by JavaScript, for example, file uploads, file downloads, etc. We let the proxy intervene and do that. So for example, like, for file uploads there are two different ways, actually three different ways we do it right now. One is to actually do something to do with data transfer object, okay? So one thing was that I don't remember exactly what our implementation is right now. The second one was to be able to use native events for those file uploads. The third one was to actually delegate it to the proxy to be able to upload those the content of the file to the end server, okay? If those don't work, of course, we fall back to the OS level native events. And OS level native events are, like, you know, we trigger it through AWS, Java AWS or through Windows APIs. So one thing that actually, like, we struggled with for some time was normally JavaScript events where we did not need the browser to be in focus. So we would actually, like, you know, we were doing parallel playback on a single machine. So we would do, like, five, six browsers or, like, how much ever the CPU can support that many browsers running in parallel executing scripts. And then once, but when we have to actually, like, you know, resort to the OS level events, then we had to have this mechanism of, you know, locking the other windows, like bringing that one particular window into focus then do the event simulation and then, like, resume everything back. So right now the product has it, but, like, I remember that we had trouble with that. So then for native events, we had to do it sequentially, et cetera. So but now it is, it is all solved. Automatic weights. This has been something that people think is kind of a hard problem to solve. It actually isn't, okay? So Sayu waits for page loads for frame and iframe loads and for any Ajax activity. The tricky part is basically the Ajax activity thing because the other two give you callbacks. So for Ajax activity, like, what we have done is the XML HTTP request object itself. JavaScript allows you to actually overwrite any object in the DOM, okay? So basically, you replace it with your wrapper object which internally calls the actual object, okay? And you put in hooks at the start and end. And what we do is keep a count of all the extra requests that are going on. And when they have all network activities as subsided, which is all Ajax activity as subsided, then we go and trigger the step. So the way Sayu works is when a script executes, a step is put for execution in a particular place. The browser comes and picks up that step. The browser or the Windows desktop or the Java application or whatever, they'll come and pick up that step, okay? And we'll see whether they are, whether the application is ready to actually execute that step. And before execution, it will check whether everything is, you know, the pages loaded, et cetera, the things that we're talking about. And only after it sees that all of that is done, will it actually go ahead and execute that particular step. And so this gives you, you know, like, you don't have to worry about waiting for things. Now if it fails even then, okay? So what Sayu will do is it'll take two seconds and then retry that particular step. And if it fails still, it'll do that for four, five times, five times, actually. So this means that when you actually see something, really something fails, it will take about 10 seconds to fail. And in case the system is required, so there are some applications which uses, which use set timeouts, okay? Set timeouts can actually, they are not in the, so if you say set timeout one second and then like your, whatever your function is, like it'll trigger after a second. And there is no way you can actually know when it is gonna happen. So of course we could have actually like hooked into the set timeout also, but for some reason we didn't, and like we just like wait for this and see if everything is fine, if things are fine, you go ahead and execute. So all these three things that we talked about, right? Kind of makes Sahis tests are not brittle. So you don't hear that word so much with Sahis automation scripts. Which actually like has been, I think that there is a misconception that like automation is inherently brittle. It is not. And all this talk about you know, hey, the pyramid and like, you know, you should like write the minimal number of things at the top, et cetera. They're all fine, but you know, the end user is actually interacting with you from the user interface. There is a high level of importance to that particular, you know, small apex, like, which is the automation test. And getting it right and having a good suite that can actually go through your interactions is a valuable thing. So the industry has like, you know, kind of moved saying that in not moved really, like, but they kind of like say, you know what, hey, we'll only do API testing, we'll only do unit testing, like the things are brittle. It need not be. You just like, you know, it can be, it is a solvable problem. It can be solved. Now recorders, okay. Another one of those maligned little things which are like super duper awesome. So we have had recorders since 2005, and it makes life super easy for the test automation. Okay. In fact, for the test, I shouldn't say just automation. Okay. So one thing that recorders do is like, you don't need to know everything before you can start doing something. It gives you a good stepping stone. Okay. And because like Sahi doesn't need weights, you don't need to introduce anything because it doesn't need X paths. Your object identification is already like much easier. There are places where you will need to manually intervene to do the near and in etc. But like there are those are like much lesser places and we have ways of actually making it very easy and even simulation, you don't have to worry about it too much. So if as an end user, if you're clicking it, you're clicking it. That's it. We don't have to see whether you're mouse downing it or mouse uping it like that. So like you clicked it, you clicked it, you that is what you did with the mouse. So we just like, you know, handle everything internally. So because of this, the recorder works very, very well. Like you can go like 70 70% of your way with with the recorder now of the way of automating the flow. Okay. Not really organizing a chord. Now as I said, like, you know, good recorders with smart identification, they can remove the need for writing code for automation steps. They can do it pretty much. Okay. And Cypro has recorders for browsers, desktop, mobile and every technology it supports supports. Okay. Even for our API automation, like, you know, you use switch on our network logging in Sahi, you do your request responses and you can actually import that request into the API thing into the API testing part to build your test cases for that. So recorders we feel are like super important and because we have worked closely inside the technology inside the, you know, like runtime of each technology, we can get really good identification mechanisms fairly fast, not too slow and across all these technologies. So there are a couple of couple of points that like come up in automation circles. Okay. That, you know, automation code is production code. Okay. We don't believe that at all. Automation is not production code. Okay. There are a lot of reasons, but any guy like who's actually written good unit test will know this that, you know, your code needs to be really, really simple. You need to be able to like check a particular condition by just modifying that part without like touching everything else. So if you're making it complex with like for loops and like, you know, if conditions, etc, then like, you know, you need to write tests for the test itself, which is like kind of, you know, stupid, like you'll go on doing that. So this is not inception, right? So this can have repetition. So like, in fact, like most of the tests are right, like they have repetition. They build that they, you know, set up the same things again and again, they do like, you know, pretty a lot of things is repeatable except for some changes. Now, why is it okay because it is a test if it fails, you'll find out and the thing is if it doesn't fail and like, you know, if you're looking at it and if you want to actually see if you want to fix something in the overall application, you need to make that small change, not worry about anything else because you have another whole product to worry about. So like, you can worry about that, but only change this particular test in that particular one line and then go ahead and not worry about all the other tests that it actually touches. So it is okay to have repetition in this and this is very important. Okay, this should be very easily modifiable. Why do I say that because the more structure and the more like, you know, things, you know, structure that you give to your test, the more rigid they get and your hesitation to actually change it and to make your application work is going to increase a lot. Like, a lot of you won't touch tests like, you know, which have like lots of complexity. You don't know what is going to fail and like, you know what happens when automation scripts fail, right? Like there's a whole stigma attached to that. So keep it as simple as possible and keep it as light as possible, right? And this is like what we did. We realized that most automation tool functionality can be productized. So the execution control, the test organization, the reporting, all of this is actually like, you know, it doesn't change from product to product. Sorry, it doesn't change from, you know, your one project to another project, your one company to another company. They're all standard things. And the only changeable thing is your business logic and the flow of the application. So you own that part, the rest is owned by the tool. So that is what like our aim had be. Now, if you look at Selenium, right? Like it believes that, you know, hey, you have this library, okay? You do whatever you want with it, right? So basically the, I believe that, you know, the way WebDriver has evolved is for other layers to pick up WebDriver and to use it underneath as their engine. Now, WebDriver gives you the freedom to build any kind of tool that you want that suits you, okay? And well, like we believe that, you know, hey, just take the whole tool. Just use it as it is. It's very simple. Like, you know, you don't need to be an expert to build that particular layer. So you can just, like, go ahead and test your automation and test your application. So this is another thing that is kind of a fud in the overall automation world that the automation and application code language has to be the same, you know, hey, the testers and the developers write code in the same language and it makes it all easy to actually, you know, make it work. Honestly, it's not, it's not at all useful. One of the first premises, like, okay, so your application was built on PHP from an old time and then now you want to move to Node.js, let's say. Now, if you are just written in PHP, like, will you be able to actually run it on the Node.js thing? If you are actually, like, sharing models and other things in there, like, then you're kind of, like, you know, messed up, you can't do it. And the most critical juncture for, like, where your tool should be, you know, useful is this, is when, like, you know, you're, when you're actually doing such a big port. So it is, it is kind of very important that, you know, like, you kind, you keep these mutually exclusive. It is okay if the tester, actually, like, you know, works in his own silo with his team. The point is to actually have enough trust between the two of you to actually say that, okay, hey, you know, I built this. Is it working? Not working? Okay. And have communication. But the code level, you know, sharing is not at all necessary. It also, like, makes it very tough, you know, something, the tests fail, you don't know, like, whether it failed because of the, you know, development code or because of your own test code. It's just a mess. You shouldn't get into it. They should be, like, you know, in different, I would believe different silos. They should, like, you know, work independently of each other as far as the code goes, but talk to each other as a team would. The other thing is, this is, like, if, if, as, if an end user did not need to know your programming language of your application, why should the tester know either? So the tester is, like, you know, if you're talking about functional testing, okay, functional testing doesn't really need to know that. And we kind of, like, you know, kept it simple. So initially, one of the selling points of selling was that, you know, you have drivers in all different languages. Okay. We didn't really, like, you know, like, we didn't need that. So we said, okay, you know what, we'll only do JavaScript. But then, like, there are other people who are integrating us into their, like, you know, RPA tools or like other tools who needed a Java driver. So we also have a Java driver along with it. But overall, like, we kind of say, you know, hey, which is the simplest language out there, JavaScript, just use that. Okay. Okay. This is another thing that, like, I have, I've never, like, figured out why it happened like this. So WebDriver has a W3C standard. Okay. If Drossus really wanted to adhere to standards, they would have done it for the HTML part, the JS part, and the CSS part. The reason there are so many differences is because each one had wanted to be, you know, have an edge over the other. Now, by the way, like, a lot of innovation has happened because of that. Ajax came in because of, like, you know, surprisingly Internet Explorer. Okay. And then, like, you know, Google took it with its, like, Gmail interface and, like, take it to the next level. And a lot of things happened because, like, each one was trying to be better than the other. So now, to actually say that, okay, they will all adhere to a particular standard is, was questionable. And now, like, it's like, you know, hey, forget, like, the standard. You have only one browser, one, you know, one browser engine now for all of these edge, Safari, everybody has moved to what is, like, behind Chrome. So, but the thing is, our belief was, you know, you didn't really need a protocol, and we didn't believe that, like, people would actually do that. And an early warning sign was the Marionette driver coming out of Firefox. They wrote their own, you know, web driver modification of the protocol and did their own thing. So it is not easy to actually have something like that. So we say that, you know, hey, we will stay aloof of the browser. We will actually, like, you know, look at, we will ensure that the customer gets a good automation tool, irrespective of how the browser is changing. So that is what, like, our focus had been. So that is something that I have always questioned, like, why is it W3 standard? Okay, this, I think I'm almost out of time. Okay, so there are just two, three, two, two things that I would say, why we moved away from open source, the problem needed a lot of time, okay, and effort from us to actually keep pace with the technologies. Browsers were evolving really, really fast, and, you know, I couldn't do it part-time, and I liked the problem. So I wanted to do it full-time, so I said, okay, you know, I need to figure out a way of making money out of this. The other thing that happened was, like, because our tool was focused towards testers, we realized that, you know, they could figure out bugs, they could find out, like, you know, feature request that they needed, but they couldn't really because, like, we were targeting people who couldn't really code too much, and they wouldn't be able to contribute via code. So it was okay, so it was good that, you know, they at least contributed in how they used it, right? And the third thing was, like, you know, it was a lot of, like, you know, ego, you know, ego management that you had to do when you actually pulled on contributors. They had, like, different visions, you had to actually manage all that, and it, unless, like, we were working closely in a team with each other, facing each other, these things have their own problems. So it didn't really work out. So support was, like, another thing that was really, really needed, and what happened was, like, many of our customers had very specific problems of their application or in their environment, so they wanted to show, like, what it was like to actually, what that problem was, and they wanted to get our, you know, fixes for that particular problem. Now, we couldn't do via the open forums, and, like, we had to, like, figure out, like, some way at some point, there were more people wanting support than I could. Okay, so I needed people to actually, like, sit there and do that, and there are NDAs to be signed with a lot of organizations to say that, okay, I saw it, but, like, I'm not talking about it, etc. So there are these things, like, you know, if you, if you, when we went commercial, we could do all that. So one thing that I found about commercial software was it was true and fair, which is, like, kind of interesting to note, because it's involving money, right? The bad thing. But, you know, it was very simple. There was a simple contract. If you needed our support, and, like, you know, if you like the software, you pay for it. Otherwise, you're free to use it, you know, you're free to not use it. And we could concentrate on people who really paid for it. We didn't have to worry about, like, how we were talked about on the internet at all, which actually is a big problem in the sense that, you know, people have opinions, and the more popular, like, something is, like, the more opinions are in favor of that. So you don't really, like, you know, there is not much, you don't feel good in that overall atmosphere. So you kind of say, you know, hey, you know, that's all, like, you know, the overall what do you call it, you know, this social messaging or, like, whatever you do, you know, that you don't need to pay any attention to that, you know. So there is no image to maintain. There is no repetition to actually, like, kind of take care of, etc. You just, like, do your work, get paid. And that's it. We built, like, we have about, like, 10, 11, programmers who actually work on the product on all these, like, different lines. We don't have to, I can set the vision and, like, you know, we can actually work towards that. That is, like, a very powerful thing. And people have time. So, like, six months on a project, any guy given six months to actually work on a problem without any distractions will come out with, like, excellent stuff. The same thing to be able to do part-time over, like, multiple months, years, maybe. It could, it may work, it may not work. So you don't know, like, what you will get out of it. So we could steer that focused innovation because of that. We could pay for a customer support team with online meetings, like, 24-hour response time, etc. And we have stayed bootstrap because, like, you know, we wanted to stay true to the essence of, like, what we were trying to build. And that's, so if you look at it, like, people will say that the framework has courteous support, which is quick to provide solutions to problems and questions. As I propose, maintenance and support efforts are unbeatably low, right? And if a problem should occur, the support is able to solve the problem very quickly. Now why am I actually bringing this testimonial here? Because I have been bashed on the internet and, like, people have said, you know, hey, if only you had a bigger community, we would have actually, like, picked your tool. My point is like, you don't really need a bigger community. You need to solve the problem rightly. You know, you need to be able to help people in whatever way. And if doing it via closed commercial support actually helps the customer, go ahead and do that. Like, it is there is no real, you know, it's not like in a, hey, open source, like the Holy Grail and you have to do that only and you can't do anything else. Nothing, right? You have to solve the problem, right? So that's what we chose. Now the trade-offs of going commercial, no fame. You know, this, like, we nobody knows what's actually, like, nobody talks about it, okay? But overall, right, while it is it matters in the sales process, most of the sales has happened through word-of-mouth, okay? Now, if it was more popular, it would have been nice. But, you know, like honestly, like, when we were doing that it wasn't the best thing that, like, you know, it wasn't really what we needed, okay? So as I said, like, word-of-mouth, that's how it spread. And we can't afford marketing in a lot of places because we are bootstrapped. And as soon as we went commercial, conferences expected you to pay because you're a commercial company. And honestly, like, as I written here, you know, conference talks care me. So I was acquitted, you know, okay. I don't pay, I don't talk, that's it, fine. So our vision to be is to be a good solution, you know, not necessarily a famous one. This, like, okay, all the things I'm saying about fame here, right? It could be very, like, a case of sore grips, right? So it's even very free to actually, like, ignore all of this. But, you know, that's what I'm convincing myself of right now. So was this overall thing a success for me or not? Yeah, as it depends on your personality, right? Like, I don't want to engage online, argue online. I don't want to manage people too much. I don't want to have, like, any social positioning, etc. So it's kind of, you know, it keeps it simple. I have my time to do, like, you know, things that, like, I like, my team has, like, all the freedom to do whatever they want. It's, it makes it, like, very simple and clean, okay? So for us, like, it feels like it's not bad, okay? As I say, like, you know, going commercial helped me and my customers. Yeah, mileage me very. Okay. So that's, that's the difference in the overall part that we had taken, right? So we took a lot of, like, different technical decisions. We took a lot of, you know, commercial decisions on how we wanted to go. And that's where we are. So if somebody wants to learn Cypro, they can go to academy.cypro.com. I think it'll be up in a couple of days now, where we have these tutorials, et cetera, and, like, you know, a free license, et cetera, for learning. But otherwise, like, you can these are the things. Yeah. So that's it. I think I overshot by quite some time. Sorry about that. All right. Awesome, Narayan. Thank you so much. I, from the first day I met till now, I love your energy, you're opinionated, you know, that that's what makes someone what they can do, right? Like, it's amazing. So, again, I appreciate that and appreciate you coming and sharing without any, what should I say, you know, sugarcoating things, just putting it out right, you know, that's your personality. I've known you that way. And I appreciate you remaining that way on screen as well. And you put out things very, very nicely in terms of, you know, what your thought process is. I am looking at the lights here and it's just amazing, you know, almost 4500 lights. Thank you. That just shows that people do care for authentic you know, content from you coming directly. And again, you know, I think both these products are great. They have contributed massively to the community and help each other, right, in terms of ideation in terms of taking it forward. So again, thanks Narayan for joining us. I know it was a difficult talk for you personally, you know, walking this borderline is very, very hard and you did a fantastic job. So thank you again for joining today. I'm really sorry folks, we are out of time. But Narayan is going to be available in his speaker lounge, the VIP speaker room. And you know, you can please take the questions over there and ask more interesting questions to Narayan. So he will be there, you know, for I'm hoping for another 60 minutes with us, you know, and you know, please take your questions there. Now I'd request everyone to jump to the next session, the important announcement sessions where I want to quickly talk about the slides and videos. People have been asking about that. I have updates on those. We also want to announce a special contest that we want to run today. And finally, you know, just want to get all the volunteers on the stage to acknowledge them. So maybe Narayan, I could also request you and then maybe be available in your speaker booth so people can join you over there. So thanks everyone again for joining in. It was amazing. We will see you in the next session. You can click on the stage and join the next session. Thank you very much.