Democratize Automation to Build Autonomy and Go-To-Market Faster

The full transcript

Kavya (LambdaTest) - Hello, everyone. Welcome to another exciting webinar session of our Lambda Test Experience Series. This session is on democratizing automation to build autonomy and go to market faster. Our Experience Series features renowned industry experts, as well as technology leaders who have vast experience in the space of testing in QA. And we are very excited to have you all with us today. I'm Kavya Nair, Director of Product Marketing at Lambda Test and your host for today's episode.

Today, we have a distinguished speaker with us, Vadeesh Budramane, the founder and CEO of AlgoShack with over 33 years of experience focused on product engineering, innovation and IP creation. Today, Wadish brings a wealth of knowledge to discuss in today's episode. To give you a brief about Algoshack, it's a startup born agile platform that transforms software delivery by leveraging AI and deep technology aiming at auto coding that is self-learning and easy to maintain. To give you a gist of what today's episode is all about, we would be exploring the concept of democratizing automation and how different stakeholders engage. It will be more around how automation is advancing and helps sprint cycles to shift to the left. We'll also deep dive into how low-code, no-code platforms play a pivotal role in this process.

So without any further ado, let's jump straight into the heart of discussion and kick off today's episode. Over to you, Vadeesh.

Vadeesh Budramane (AlgoShack) - Thank you so much, Kavya. Let me share my screen is visible to everyone. So yes, as Kavya introduced, the topic is about democratizing automation. And I'm really very passionate about this. It's about inclusivity. It's about comprehensive coverage. I'll talk more about it as we go through the slides, but let me quickly set the context as well as to what's happening in the industry today.

With gig economy, software has become the key differentiator for businesses. Every business is turning to be a digital business today. And in that context, every business is trying to engage with customers in newer ways.

There is sassification which is more happening now than before and machine learning is becoming more reality than before. Under these circumstances with this backdrop, what's happening with software companies is that they are under tremendous cost time pressure to take their products to market faster in quick succession.

And as we all know, one third of software development, one third of software development effort is in testing or test automation. When I talk about testing and test automation or automated testing, I synonymously use these. You know, there is a reason why I do so, I'll get to it in a minute.

Testing being a third of software development effort, test automation becomes very critical. And traditionally, test automation has had many challenges. Test automation has been, you know, manual resource intensive, time consuming. As a result, it takes time to automate testing. Coverage is, you know, incomplete.

There are significant challenges with scaling automated testing. And obviously, it eats into a lot of cost. To highlight the scalability issue a bit further, there have been far too many tools in the market. There was a time when people thought, you know, selenium is the panacea for all challenges with automated testing, but that was not to be. You know, soon we were encountered with several other tools such as, you know, Appium, you know, Cypress, Playwright and Sikuli and whatnot. And it takes significant effort from people to keep pacing with these evolution of tools. And it is hard to know really master each and every tool in the horizon. Of course, there have been evolution of test frameworks trying to resolve these challenges with automated testing. You know, it all started the framework began with record and play probably 15 years or 20 years ago.

And then frameworks moved on to becoming data driven frameworks, keyword driven frameworks and BDD based frameworks and the current framework that is further evolving is the full stack framework that leverages machine learning. While these frameworks over the years have tried to address some of the challenges that I just discussed in the previous slide, there is lot more to be done. And if you look at the current trends, they revolve around two key aspects, one is low code, no code and another one is leveraging machine learning. And there are there are a couple of more emerging trends and I'll discuss that in a minute. Now when I talk about low code, no code, I don't mean No code as in no script at all.

It's about you know, it's about scripts, but not spending time to deliver those scripts. In other words, no manual scripting efforts, but it'll have scripts, scripts in the technology of one's choice. You know, it could be Java, JavaScript, TypeScript, it could be C sharp, it could be.NET. You know, it could be any of the tools that you are familiar with such as Selenium, Appium, Cypress, Playwright, WinAppDriver, it could be FlyUI, it could be REST assured scripts, it could be REST sharp and whatnot. So what we're talking about is scripting without manual efforts, scripting produced by a platform or a tool scripting in the technology of your choice that could run anywhere, anywhere as in third party cloud such as Lambda test. So that's the platform that we are talking about. That is the trend that we are talking about, low code, no code.

And these help with faster automation of testing and it'll empower anyone and everyone in the ecosystem to contribute to automation of testing. And the other key trend is about artificial intelligence and machine learning and its application to help with habitual continuous testing. Testing or the test scripts that are self-healing, that are auto-healing, so that you can truly have autonomous testing. So that's the second trend. And the third one is to make.

Test automation unified, comprehensive, not only covering UI testing, but also testing of microservices and web services, as the case may be. Now, let me quickly add, one should also be able to test. SaaS or platform as a service without requiring SAS applications to be developed to be able to test PaaS platforms. So in other words, you should be able to test PaaS when PaaS is ready or even as PaaS is evolving and not requiring you know, developers to build apps on top of pass. So that's the third trend that is shaping up the current fifth generational test automation framework. And last but not the least, the frameworks, automated testing frameworks have to support in sprint automation.

In other words, even before a single line of code is developed, you should be able to initiate the process automation or automated testing. These are the four key trends that is further shaping up the evolution of fifth-generational test automation framework. Now, I talked about low code, no code platforms in some detail. I said, it's about scripting, but not requiring manual efforts. It's about platform producing scripts. It's about platform producing scripts in the technology of your choice. And it's about scripts that can be executed anywhere without any kind of locking, without any kind of monopolizing. And that's when you can actually liberate, democratize automated testing. And when you have low code, no code platforms, then developers, they don't have time for testing, but with low code, no code platforms, they could automate testing within a sprint.

When developers contribute to testing, then the silos in test creation, they get removed. In the process, testing becomes a lot more effective. And likewise, it empowers manual test engineers to automate testing. And when manual test engineers automate testing, then the adoption of automated testing it increases the chances of adoption increases and it improves you know automation you know as manual testers embrace test automation. It helps you shift automated testing to the left into in sprint process, automatic testing can become part of a scrum team activity, thereby making testing more effective and also enhancing the development productivity of a scrum team.

And when you have scripts produced in the technology of your choice, and your choices could vary from time to time. You know, there was a time when people used protractor and protractor got deprecated or being deprecated. And now people are trying to see whether to move to Cypress or playwright or go back to Selenium migration would become seamless when there is a platform that produces low code, no code scripts. It will become a, you know, click of a button. With the click of a button, you will be able to move from protractor scripts to Cypress scripts.

And that's the advantage that you get when you use low code, no code platforms. Your test automation becomes foolproof, future proof. And obviously, quality improves because of the inherent reuse there. And it reduces the cost of automation, thereby reducing total cost of ownership, and helps reduce automation debt or tech. So, those are the advantages of low code, no code platforms and talking about machine learning in the context of, you know, cordless scripting, there are many use cases of machine learning. You can create tests without you having to design, without humans having to design. You can have machines design test cases. You can sense application changes automatically. You can come up with the forecast against each test case, whether it is likely to fail or pass when it is executed next and that helps you with scientific choice of test cases for your regression suite. You can improve speed of execution.

You know, you do not have to wait eternally for an element to shop, you know because you have deployed machine learning, you know how long it takes for an element to respond. So you can optimize, you know, test execution. You can become more smarter with your execution and you can also predict root causes for test failures. You know, whether it is a locator issue, whether it is a sync issue, whether it is a data issue, whether it's a true application issue.

So, categorization of defects or issues can be done by machine learning algorithms, saving lot of time for testers or automation engineers. And self-healing results in reduced maintenance overheads. And there are times when you have too many test cases and you won't know how many of them are really duplicate. I've seen cases where, you know, there were 65,000 test cases in a test suite for one application and automated deduplication saves a lot of time, effort and cost. So these are the use cases of machine learning or artificial intelligence that is gaining significant traction with these low code, no code platforms.

And by the way, Algoshack has a platform called AlgoQA that is low code, no code and leverages machine learning wherever it really matters. Now, I talked about you know, local no code platforms. I talked about tools that will, you know, help, you know, invite participation from the entire ecosystem. You can invite participation from developers, you can invite participation from test engineers, manual test engineers, you can invite participation from product owners, subject matter experts, you can invite participation from architects, test architects and automation engineers. And now, the question is, when there are such tools, you know, how do I, available in the market, how do I go about choosing them for my situation, you know. So one needs to analyze one's own situation, you know, is your situation a greenfield situation, whether you are into new product implementation, whether you are looking at automating for the first time and so far you have been testing manually or whether you are going for you know classification for the first time. So those offer greenfield situations and probably choosing an automated testing platform is easier in such situations. I'll talk about what questions to ask in another slide to be able to arrive at the right choice of the tool.

Your situation may be a brownfield situation where you automated testing in the past, but you used, you know, a technology that is being deprecated. Now you have to make another choice. Or you have been automating, but your automation coverage is limited for whatever reason it hasn't crossed 45, 50% mark. And there have been challenges with the execution. Execution has been slower for whatever reason. You know, I've had cases where we had to recommend to people to move to JavaScript Playwright as opposed to Java Selenium to help them with faster execution. Or you may have a situation where maintenance overheads are very high, your scripts are rendered flaky every now and then, instead of working on automating newer test keys, you end up spending more and more time in maintaining scripts that you once automated. Or for whatever reason, you picked up a framework that is quite closed and not open at all in which case you will be tied to that platform and its inefficiencies forever. And in such cases, you will want to migrate to a newer tool or a newer platform or you may want to switch from an expensive framework to an inexpensive one, an open source one.

And likewise, so, or you may have an application that is not testable and you want to, you know, really look for a platform that helps with such situations. Or you may have a case where you really need platforms to support distributed testing. You know, you have coordinated workflows, for example, as it is the case with, you know, web applications that leverage, you know, web RTC technologies. To give a simple example, let's say there is a tool that supports video conferencing. So you need to test for coordinated workflow across users that would participate in a video conference. So, your requirements depend on your situation, your approach to automated testing, your automated testing strategy would vary based on what is your situation. Now, depending on your situation, you have to ask some more right questions to be able to choose an appropriate test automation platform. You may have your hardware interactions involved in your test cases. Your application is a software application, but it involves hardware interactions.

You know, we have come across applications in the medical devices world that involves significant hardware interactions, whether you are dealing with CT scan, you know, x-ray scanners, whether you are dealing with MR machine, there is significant hardware interactions involved. You may not want to leave it for the platform to decide on the scripting tools and scripting technology, you may want to choose what technology you want to go with because your you come from a regulated industry and you have chosen a tech stack and there is no way you can move away from that tech stack and to add to that tech stack means couple of years of validation efforts. Likewise, you know, your domain is unique, it is always unique, each domain is unique.

Now whether a particular platform can cater to your domain. You may come from digital commerce, you may come from enterprise software world, you may come from healthcare world, you may come from FinTech world, then you will have to check whether the platform could cater to your edge cases. You will have questions and you will have to ask such questions if your team will have to switch to a new way of working. You may have an application that is not testable. So you will want to check if the platform or the tool can automate your green screen application. You may have a framework readily built. It's not scaling, but you still want to leverage the work you have done in the past. So, you may want to check the tool that you are seeking to use can serve as an extension to your existing platforms. You may have questions about folder structure of the scripts. You may have questions about coding guidelines followed. You may have questions as to where to execute the scripts.

You may have questions as to what happens to your existing investments. You know, you may have questions, you know, as to how you could repurpose your team, your people. So my view is that a true platform that piggybacks on the current trends, current trends in the automated testing market that follows the fifth generational framework that I talked about would address, would try to address most of these questions and that is what we have done with the AlgoQA. With AlgoQA you could you know have scripts in the technology of your choice, scripts could be executed anywhere, scripts could be executed on Lambda test.

And let me also add about Lambda test in this context. If you look at Lambda test, Lambda test supports execution of scripts and scripts in the technology of your choice. And this is more true and more real with Lambda test new offering called hyper execute or enterprise execution environment. It addresses situations that we couldn't address at one point in time where you have heterogeneous systems, you have scripts that are written in varied technology frameworks. And here is one product that helps you, you know, execute them all in one place and helping with continuous testing helping with autonomous testing, helping with testing that is continuous, that is comprehensive, that is more inclusive.

So let me quickly add what are the do's and don'ts when you choose a tool for automated testing look for support for BDD, behavior driven developments, that way you will have standardization. BDD means you have feature files that are written in working language that can be interpreted by anyone and everyone that can be interpreted by product owners that can be interpreted by you know, test engineers that can be interpreted by architects alike. And you have to have support for, you know, web applications, mobile apps, but also for desktop applications, you know, embedded software, you know, microservices. You will not only require support for functional test automation, but also non-functional test automation.

Let me again add this exactly what is happening with the hyper execute. You know, in the past, Lambda test would support mobile apps, would support web applications. But with the hyper execute, Lambda test is extending it to, you know, standalone applications, desktop applications and so on. And there has to be support for single click to execute. There has to be one system, engine in order to realize the true benefits of automated testing. And the tool set must support not only open source frameworks, you know, such as, you know, Selenium, Appium, Cypress, Playwright and the likes, but also, you know, COTS framework such as Squish, such as, you know, TestComplete and so on, so that you can really address test automation challenges across the board, you know, including that of applications that are desktop based.

And obviously, a good test design is very critical to, you know, automated testing that leverages unit tests, that leverages tests based on APIs, that leverages end-to-end tests in good proportion, a good test design that has significant reuse. Instead of writing more and more end-to-end tests, it helps to write component tests and sequence them to form end-to-end tests that would help reduce number of tests, help reduce the effort required for automated testing or effort required for automating those test cases and effort required to execute them. So those are the do's and do not try to over engineer scripts produced by a local no code platform. Do not try to force fit it into your existing framework. Try to liberate but do not try to over engineer and do not try to manually maintain those.

Now, ensure that they comply with your coding standards, they comply with your maintenance requirements, but try to leverage that helps you scale automation, that helps you automate more and more, that helps you go to market faster rather than going back to what one used to do to write them manually and write as per one's fancies. That is not really going to help in the current market dynamics, what is important is to go to market faster, of course, without compromising on quality. So this is not really about having to maintain my skill set in Selenium, but about being able to apply technology to solve some of the real world business challenges.

So, democratized testing or democratized automation invites participation from everyone. It invites participation from developers, testers, architects, product owners. It invites participation from cloud execution vendors, partners like LambdaTest, it invites participation from the likes of TFS, TestRail, HPALM, ZOHO, and Jira and so on and so forth. It invites participation from likes of spec flow, cucumber so on and so forth. Nothing limiting, no silos, no monopolizing, more open, highly liberated. And once you have democratized testing or automation. Then you can actually automate anything and everything right from development all the way through to deployment. We have cases where people leverage automated scripts in production environment, not limiting it to engineering process.

And you can truly realize continuous testing, autonomous testing. You can have machine learning models learn, you know, on an ongoing basis. Of course, it calls for significant collaboration between humans and machine. But once you have trained systems, they help you with auto-healing, they help you with self-learning, realizing continuous testing extending the benefits of automation not only to testers, not only to customers, but also to developers shifting the process to the left. And when you leverage such tools, such platforms that help you democratized testing, democratized automation, you will be able to realize a return on investment upwards of three and your citizen engineers will be able to do a lot more with less.

So with that, I'm open to questions.

Kavya (LambdaTest) - Thank you so much, Vadesh. That was very insightful. In fact, very interesting to see how you have outlined the evolution of test automation framework, automation trends, and even the rise of AI, because these are the very topics that our audience, that is, testers and developers, want insights on. Now, onto the questions. The first thing that we wanted to know was, how does slow and siloed system design and test creation impact the ability to meet tight deadlines, thus delivering the software products to market faster. And is the democratization of test automation the only solution?

Vadeesh Budramane (AlogShack) - So, yeah, I mean, what happens is there is very little collaboration in the past when it comes to automation of tests within a sprint cycle. That is because, you know, by design, there would be more developers in a scrum team and less number of testers and the focus is on developing and not so much on test creation, certainly not on automated testing. So, the process of test creation is slower, the process of automation is slower and it results in significant quality challenges, it results in lot of you know tech debt, you have to automate testing downstream that used to be the situation but then with this democratization, you know with such tools now making test automation very easy, very fast, quick.

Developers are able to automate testing in Sprint. Obviously automation engineers are also able to automate testing. The manual engineers that were part of this cram team are able to automate testing in Sprint. So by the end of the Sprint, you have not only code that is unit tested, but also you have automated scripts that have tested the code not for unit testing, but also for component testing and end to end testing to the extent that is possible within a sprint cycle. So that makes your verification cycles a lot more smoother, that makes your downstream validation cycles a lot more smoother. So I think.

Democratization means removing barriers. It is about inclusivity. It is about making things a lot more comprehensive, lot more effective, lot more efficient. It is about reducing the need to have more and more technical skills. It is about leveraging functional people to their fullest potential. So obviously it's all for many issues that resulted in slowness, that resulted in siloed approach that increased cost of quality in the past.

Thank you, Kavya, for that.

Kavya (LambdaTest) - Thank you so much. The next thing that we wanted to understand was how can organizations, especially enterprises or digital natives ensure that automated testing process remains compliant with industry regulations and quality standards while adapting to customized business processes.

Vadeesh Budramane (AlgoShack) - I think that is a great question. We have, you know, when we approached some of the regulated industry segments such as medical devices, they you know, they expect significant degree of transparency. They would not read testing as a black box, they will not read automated scripts as a black box, they will want to review automated scripts. They have to be validated before they are executed. Because the reports produced by automated scripts have to be submitted to FDA for regulatory reasons. So you have to validate the scripts. So you can't say that my scripts are proprietary. I only best know them. And my scripts can be run only on my platform. That wouldn't work. In the first place, you have to make you have to produce scripts in the framework that is acceptable to the industry segment, that is acceptable to the customers that you are talking to.

And not only would they have, you know, guidelines for scripts and choices for technology, they would also have documentation practices for feature files, documentation practices for test case document that these low code, no code platforms produce or expected to produce. And there are guidelines for reports as well. What logs to go, what screenshots to be attached, where do you have to have video clippings, what all to be verified, at what degree you have to verify them. So everything is specified, you can't take chances. So you have to cater to such requirements only then would a low code, no code platform be successful in regulated industry segments. And low code, no code platforms would provide for horizontal solutions, but must cater to the industry specific requirements. If you are in front of a med devices customer, then if you are talking to them, you know, for their CT scan-offs, then you should tell them how your platform helps automate test cases that have hardware interactions.

In other words, your platform should be extensible to cater to the edge cases should be extensible without requiring customization as in modifications to the platform. They should be able to do it at the user level by way of configuring. So this is a very critical requirement and this is one of the things that test automation vendors have to cater to. Without which, you know you will not be able to cater to edge cases, while edge cases may not be significant portion in some cases, but cases where you know, it is a, it forms a significant portion. For example, scanning ends with you know, you pushing the hard button, there is, you cannot end scanning without that. So yeah, you should be able to cater to edge cases. You should be able to cater to the need for extending the platform. And that flexibility must be offered to the user. User should be able to extend the platform on his own without requiring platform customization.

Kavya (LambdaTest) - Absolutely. Thank you, Adish. Moving on to the next question, how do you handle the balance between standardization and customization when democratizing automation, especially in industries with unique requirements? Again, the medical industry being one of them.

Vadeesh Budramane (AlgoShack) -Yeah, so medical industry, you know, automotive industry if you are looking to automate testing of a production floor, that's where I think this question is coming from. So absolutely, I think standardization by way of having BDD, BDD is common no matter what. So that everyone can benefit from English like Gherkin language. Then offer flexibility, you know, for example, one may choose Python squish, another may choose Python test complete. Someone else may have to use JavaScript playwright.

And these are driven by the type of the application. These are driven by, you know, what type of test automation are you going for? Someone may want Java Karate. Someone else may want, you know, Java Rest Assured. So you should be able to offer these by default. And that's my belief without requiring customization. And then as I said, in response to your previous question, Kavya, they should be able to automate some of the edge cases on their own, because they're not common across industry segments.

They're truly edge cases there may be some business logic that is very specific to a particular application that they may not even want to part with. They may not even want to share that with anyone. So the user of that application knows that logic best and he should be able to automate that edge case on his own. Yeah, so. That is where I call it low code, no code. I mean, no code if there is no edge case, low code if there is some edge case. Yeah, so, but scripting is always involved. The question is that whether it is scripted manually by an engineer or produced by a platform. That is the difference. You know, unlike, you know, some folks that talk about Low code, no code as in there is no code whatsoever that the user sees. I mean that is a different approach altogether.

Kavya (LambdaTest) - Right. Absolutely. Great. Coming to the last question of today's session, can you throw some light on how Lambda tests accommodate customizations and the ability to work with various tools and technologies so as to meet various requirements?

Vadeesh Budramane (AlgoShack) -Yeah, I'm actually very, very excited by LambdaTest latest offering that is HyperExecute and enterprise execution environment. You know, when you are able to execute scripts, no matter what type of application, it could be web application, it could be mobile app, it could be desktop based application, it could be a hybrid application, it could be a hybrid workflow where test case involves multiple applications. And that is what I think Lambda test solves for and that capability is very much enhanced with hyper execute with enterprise execution environment. Algosack focuses on acceleration of automation. We focus on accelerated automation. We produce readily executable automated scripts. And when it comes to where to execute these scripts, there could be many options, but one great option is Lambda test, execute them on Lambda test. Because you, you know, anything and everything could be executed on Lambda test with its hyper execute.

So Lambda test helps with the democratizing of testing and test automation. It helps with hyper automation. It helps with continuous test execution, or in other words, autonomous testing. So I'm really very excited about it. Coming.

Kavya (LambdaTest) - Great. Thank you so much, Vadesh. It has been a great session. Thank you once again for sharing your wealth of experience in democratizing automation. I'm pretty sure our audience would find it very insightful. Thanks for joining us today. And to the audience, last but not the least, stay tuned with us for more episodes on Amdutist Experience series till then, and keep innovating and testing. Thank you so much. Have a good day.

Vadeesh Budramane (AlgoShack) - Thank you very much, Kavya. Any questions, please let me know, and I'll come back on this topic. Thanks very much. Thank you. Have a good day.