Low-Code Test Automation a Journey from Skepticism to Success with Rudolf Groetz

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way o the test Illinovation Testing Podcast Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the testicle of nature Testing Podcast.

Here's a bold prediction about the future of test automation in large enterprises. Low code platforms will become the norm, contributing significantly to the agile software development process. So that's why I wanted to share with you an Automation Guild session we did in February with Rudolf Gratz who shared how Rifis and Bank International adopted their test automation strategy to incorporate a low code approach. This is a real world example exactly step by step how he accomplished this. So you want to listen all the way to the end to discover the transformative journey of moving from a traditional model to a more inclusive agile approach that include the whole team contributing to automation. Speaking of low code automation solutions, I know all about traditional testing struggles like lengthy manual regression testing which consumes valuable time and can lead to delayed releases. Many testing solutions require high code proficiency, including non technical team members from the testing process. Steep learning curves, script maintenance and the need for skilled resources and infrastructure setup are other significant challenges. But no worries. I have a solution you should definitely check out. It's browserstacks Low code automation. It helps QA developers and citizen testers streamlined automated testing with little to no learning curve. It combines AI automation best practices and browser stacks cloud for effortless low code testing. But seeing as believing so, try it for yourself. Now head on over to Test Guild me low Code and let me know how it went for you in the comments down below.

Darwinism. You know the theory from Charles Darwin that not the strongest drive but rather those who can adapt faster in the same way as species adapt to survive in their environments. Companies must adapt their test automation strategies to meet the challenges of digitalization environments. Hello ladies and gentlemen. Welcome to the Automation Guild and to my talk. I will tell you the story of how automatically and why we at Raifeisen Bank International adapted our test automation strategy to a low code approach. I will explain how we shifted from the traditional model where developers and testers deal with test automation to more agile approach involving non technical users in the test automation process. And I will tell you the story of a bunch of people who initiated a change of heart for local test automation and one person co found a new passion. Who am I? My name is Rudolf. I'm an angel Engineering coach at Driver's Bank International in Vienna. Short rbi. As an agile engineering coach I do not help our teams become agile in the sense of knowing what to scrum, what a sprint is and what user stories are. For this we have our Agile coaches. My job as an Agile Engineering Coach is to help our agile teams to implement or to use agile engineering practices like CI, CTE, DevOps, test automation and other practices. I'm also the Guild Lead for our Testing Guild. Privately I'm organizing the testbusters community and hosting six times per year the Testmasters Night. Additionally, I am lecturer in the 42 Werner programming school where of course I am giving lectures about software testing. Who is Raiffeisen Bank International Raiffeisen Bank International Short RBI is corporate and investment bank operating in certain countries with the headquarter in Vienna. Rbi, traditional conservative bank is undergoing an adaptive transformation and we use a very nice metaphor for this in our organization away from this large slow container ship dominated by command and control, low earth, fast agile, self organized speedboats. We started our transformation seven years ago and we have now around 500 speedboats with around 4,000 employees working in agile teams. We switched from the matrix organization to self organized product teams and we do not do agile because it is cool. We do it to survive in a VUCA world. You know, VUCA stands for Volatility, Uncertainty, complexity and ambiguity and describes the unpredictable and dynamic nature of the contemporary business environment. Agile means inspect and adapt and we recognize that we must adapt our test automation approach. So what is the agenda of today? You will hear about the product to be tested, the stakeholders and the mindset shift. You will hear what triggered our journey and how we selected the tools we investigated. You will get insights into how we evaluated the tool and finally you will see the result of our journey. And my last slide will show that low code tools can also be the trigger for another change of heart. One important comment before we go into details in this presentation, I will not be disclosing the names of specific tools or vendors. The focus of my talk is our journey to change our test automation paradigm. Rather than endorsing or criticizing any given tool, it is important to clarify that our primary goal was not identifying the best low code tool. Instead, it was about convincing individuals, overcoming barriers, getting rid of fears and challenging traditional test automation values. As already mentioned, I will share our experience in transitioning from conventional test automation approach to a low code approach. Let's begin with some background information to understand our challenge. Let's start with the product we selected for our transformation journey. We use the JIRA platform to validate our low code approach. 80% of our agile product teams Are using Atlassian JIRA where each country has their own cloud incense. A dedicated platform team of six people located in the Vienna headquarter takes care that the platform is operated. The test strategy is that after an upgrade of the JIRA platform, manual tests will be executed by the platform team and and some end users. Additionally, each JIRA project administrator checks if their most important features and workflows are working correctly. These tests are very time consuming and we have based on the content of the upgrade, test cycles with a length of up to 10 days and more. And of course we have a test automation strategy. The test automation strategy is already defined which should be implemented by one of the Jira DevOps engineers who was upskilled in Playwright. Unfortunately, the implementation has not started due to other. Yeah, more important tasks. I show you a number. Per year we spend around 400 hours in manual testing of the JIRA platform. Keep this in mind. Let me introduce the people who are the protagonists in this journey. On one hand we have Philip. Philip is the product owner of the JIRA platform and he is very upset with the current test strategy. He wants business people can also automate tests to shorten the manual test cycles. And then Rudolph, that's me. I'm not a fan of low code platforms since I have never seen a successful implementation of this approach before. And for me it is a fact that test automation is software development. For me, low code test automation is only marketing and sales yelling. And then we have Thomas. Thomas is agile engineering coach and the test automation chapter lead. He is highly convinced that low code test automation cannot scale in large enterprises and therefore it is doomed to fail. And last but not least, Tim, the holiday intern biomedical student. He has no coding know how, no idea how this automation works, no idea about software development and the internship was not his idea. Now we come to the question why it was necessary to evaluate the low code approach for test automation. At first we lost the person who should automate the tests. The person who was educated in test automation with Playwright. Secondly, the person who was responsible for the JIRA test strategy left rbi. And last but not least, a new business continuity process was introduced that made automated tests mandatory for business critical services. JIRA was classified as business critical, which means the product owner had a problem with test automation. With the implementation of the business continuity process, Philippe was promoted to the new service manager and must implement all mandatory process requirements. That means Philip must solve the test automation challenge and he found a solution in adapting our test automation paradigm. And this was Phillips approach. People without coding skills should be able to automate tests with low code platforms, meaning get rid of the engineering bottleneck. Since low code approaches has already been used in the development of business applications for two years, the idea was not that far fetched and our management also liked this idea. So in the old test automation paradigm, test automation was largely in the hands of develop and test automation engineers. The tool of choice were open source frameworks requiring a technical skill set for effective implementation. Resources for test automation was always a bottleneck. What would be the new approach now? Picture a landscape where everyone in the team, including our business counterparts, actively contributes to test automation. Coding skills are no longer prerequisite. This democratization of test automation empowers every team member to engage in the test automation process. This paradigm shift acknowledges that effective testing isn't just about code, it is about collaboration, diverse perspectives and empowering every team member to contribute. Then we organized one day Destaton with product owners and other stakeholders with no coding skills. The goal was to find a low code test automation platform that we could use in a proof of concept in the next phase. During the testathon, the participants evaluated a pre selected set of low code test automation platforms if they supported the following requirements. Given our role as a financial institution, prioritizing top tier security standards is imperative. The key elements of these requirements are Data hosting in the European Union all data generated, stored and processed by the platform must reside within EU based data centers. The platform also must be hosted in the European Union. And then it was about the license model. A critical requirement is the adoption of a license model based on the numbers of test execution as opposed to traditional license. The selected low code test automation tool should offer a license model that is directly tied to the numbers of test executions. The license model should provide flexibility to scale our test automation efforts without incurring exorbitant upfront costs. Then the AI support. We aim to cater both user without coding skills and experienced developers looking to expedite the process of writing tests. The requirement is to provide an AI assistant that allows testers unfamiliar with code to express complex scenarios. This functionality will empower both testing and development teams, ensuring a seamless and accessible process for expressing and implementing diverse testing scenarios. And then we talk about test automation pattern support. This functionality is crucial for streamlining maintenance effort, especially when tests are organized into multiple test suites. And then network language was also an feature. This feature aims to facilitate a more intuitive and accessible test script creation process. This should enabling users to express test scenarios, actions and expectations in a human readable form. The tool should provide a syntax that is closely to spoken or written language. And then, last but not least, we have the live author read this feature aims to provide real time feedback, eliminating the need for the traditional write, run, debug, repeat cycle. Best outdoors should be empowered to create tests more effectively by observing a bot validating each step in real time on a headless browser. And we found one platform that supported all of our requirements. The name of the tool. As I said, this is not a product pitch. Four weeks after the destadon we did detailed proof of concept with the winner from the desert on, we got a trial license from the vendor for three months. The goal was for a person with no coding skills and no technical background to automate the set of tests for the JIRA platform which was normally manually executed by the JIRA product owner. And the person who did all the heavy lifting was our holiday intern. The goal of The POC was two great tests to validate the 25 most used Jira features, to validate the most used Java workflows, and to automate GRUD operations via the JIRA APIs. Additionally, our objective was to find out if each test suite can be executed in a data driven approach for each JIRA project in a build pipeline and the time budget was defined with 20% days and here are some impressions of the implementation. We were really amazed at the steep learning curve with this tool and how easy it was to implement the tests and the word got around. While the implementation was still underway, two other product teams decided to give the low code approach a chance. One was our on premise GitHub platform and another customized software as a service application. That means more or less within three weeks the low code test automation approach turned our test automation paradigm and upside down. And now let's take a look at the result of the proof of concept. The whole proof of concept was organized in four one week SCRUM sprints. Five days earlier as planned, we closed the POC and the holiday intern presented the results and the outcome to the main stakeholders in his presentation. The proof of concept result left the stakeholders very impressed. Even initially skeptical, product managers were fully convinced and enthusiastic about running experiments in their teams. The question was not whether to adopt this approach or not. Rather there was the question when we can start. The success of the testodome sparked immediate interest and set the stage for a dynamic shift in our testing automation practices. The future of our test automation endeavors was not a question, it was a journey that began then and now. The last part of my talk what was the outcome? What was the result of this journey first, the direct result. With the low code test automation, we decreased the test execution time by more than 80%. Let's take a look at our solution. First, we have goals. A goal is a testing scope within project. This can be a module, a component or a feature of the system. Under Test Goals help you to organize your tests logically. We have goals for features. As an example, we have goals to test our grad functions or our workflows and many others. The tests for the grad functions are divided into tests via the UI and tests via the APIs. A goal can be configured, for instance for which browser it should be executed. A goal consists of a set of tests named Test Journeys and are end to end tests. As example, for each standard workflow we have a test journey. In our case for user stories, one for creating a user story, one to delete a user story, and one to update a user story. And we have variations of these tests. For instance, create a user story with notifications or without notifications, or update a user story with the which editor or the standard editor via test plans we manage the execution of test goals Test plans allowing ad hoc or scheduled execution of a specific set of tests with the same configuration. We configure our tests that they run in a data driven way. Each set of tests will be executed for a given JIRA project where the projects to be used are defined in a test data table. If we want to run the tests additionally against a new project, we only must insert the name of the project in the data table. Additionally, we can configure whether the tests will be executed on a local browser or against a browser grid. Finally, the execution result we can see in the dashboard. The vision of the JIRA Service manager was to shift test automation activities to the business side, empowering non technical individuals to automate tests. The low code test automation approach, once met with skepticism, became the cornerstone of a more inclusive and collaborative test automation strategy. It wasn't just about adopting new tools. It was about overcoming resistance to change and addressing concern about the effectiveness of a low code solution. And we overcame these concerns, ready to take the next steps. But what are the next steps? Buying software for a bank is not easy. Supplier evaluations, compliance assessment and security outage. Currently, we are just about to closing the license back. Next, the test pipelines for Jira and GitHub will be put into operation by end of January. And last but not least, we then want to put three more test pipelines into operation by the end of April. This involves products where we do not have dedicated development teams. We have a lot of requests from product managers who want to jump on the local test automation bandwagon. Here you can see there was a change of heart by many test automation stakeholders. As I promised in the beginning, the last slide is about another change of heart. Remember Tim, the biomedical student who had no idea about test automation development and test automation? While implementing the proof of concept, Tim discovered a new software development and test automation. Because of this, he changed his field of study at school from biomedical engineering to information technology or rather to software development. His dad liked this change of heart. You know his dad. But this is another story. Ladies and gentlemen, I'm done with my talk. I hope this talk was valuable for you. Thanks for watching. And don't forget, not the strongest survive, rather those who can adapt faster.

Thanks again for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a511 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges. We're excited to Collaborate visit test guild.info to explore how we can create transformative experiences. Together, let's push the boundaries of what we can achieve.

Testing Podcast with lutes and lyres the bards began their song A tune of knowledge, A melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.