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

tgaRudolfLow-CodeTestAutomationaJourneyfromSkepticismtoSuccess511.mp3

Intro / sponsor read

In a land of testers, far and wide they journeyed. Seeking answers, seeking skills, seeking a better way. Through the hills they wandered, through treacherous terrain. But then they heard a tale, a podcast they had to obey. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation 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 testers, showing them the secrets to behold. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild Automation 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 testers, showing them the secrets to behold.

Joe Colantonio

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. That's why I wanted to share with you an Automation Guild session we did in February where Rudolf Groetz, who shared how Raiffeisen 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 .... 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 BrowserStack's low code automation. It helps QA developers and citizen testers streamline automated testing with little to no learning curve. It combines AI, automation best practices and BrowserStack's cloud for effortless, low code testing. But seeing is believing, so try it for yourself now, head on over to TestGuild.me/lowcode and let me know how it went for you in the comments down below.

Rudolf Groetz

Darwinism, this theory from Charles Darwin that not the strongest survive rather those who can adapt faster. In the same way as spices adapt to survive in their environments, companies must adapt their test automation strategies to meet the challenges of digitalization environments.

Rudolf Groetz

Hello, ladies and gentlemen, welcome to the Automation Guild and to my talk. I will tell you the story of how and why we at Raiffeisen 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 not 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 low code test automation, and one person who found a new passion. Who am I? My name is Rudolf. I'm an agile engineering coach at Raiffeisen Bank International in Vienna, short RBI. As an international engineering coach, I do not help our teams become agile in the sense of knowing what the scrum, what a sprint is, and what user stories are? For this, we have our each 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/CD, DevOps, test automation and other practices. I'm also the team lead for our testing Guild. Privately, I'm organizing the Test Buster's community and hosting six times per year the Test Buster's night. Additionally, I am lecturer in the 42 Vienna Programing 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 containership dominated by command and control, low rods, fast, agile, self-organized speedboats. We started our transformation seven years ago, and we have now around 500 speedboats with around 4000 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 vucaworld. Vuca stands for volatility, uncertainty, complexity, and security and describes the unpredictable and dynamic nature of contemporary business environment. Agile means inspect and adapt, and we recognize that we must adapt our test automation approach.

Rudolf Groetz

What is our agenda of the day? 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 endorse. 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.

Rudolf Groetz

Let's begin with some background information to understand our challenge. Let's start with the product we selected for our transformation journey. We used a 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 instance. 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 some end users. Additionally, each JIRA project administrator checks if the most important features in workflows are working correctly. These tests are very time consuming and we have based on the content of the upgrade, tests 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 hasn't started due to other more important task. I'll 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 the one hand, we have Philipp. Philipp is the product owner of the Jira platform, and he's very upset with the current test strategy. He wants business people can also automate tests to shorten their manual test cycles. And then, Rudolf, 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 jamming. And then we have Thomas. Thomas who is an Agile engineering coach and the test automation chapter lead. He's 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 knowhow, 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. Philipp was promoted to the new service manager and must implement all mandatory process requirements. That means Philipp must solve the test automation challenge, and he found the solution in adapting our test automation paradigm. And this was Philipp's 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. In the old test automation paradigm, test automation was largely in the hands of developers and test automation engineers. The tool of choice where open-source frameworks require a definitive 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 not long a 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 Testaton which 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 Testaton, the participants evaluated a pre-selected set of low code test automation platforms if they supported their following requirements. Give our owners 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 adaption of a license model based on the numbers of test execution as opposed to traditional license models. The selected low code test automation tool should offer a license model that is directly tied to the number 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 natural language was also a 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 authoring. This feature aims to provide real time feedback, eliminating the need for their traditional write, run, debug, repeat cycle. Test outdoors should be imbalanced to create tests more effectively by observing a both 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 say it, this is not a product pitch. 4 weeks after the Testaton we did a detailed proof of concept with the winner from the test on, we got a dry 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 to create test, validate the 25 most used JIRA features to validate their most used JIRA workflows, and to automate crud operations via their 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 person 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 birds 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, one is within three weeks, the low code testing automation approach turned our test automation paradigm 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 explained, we closed the POC and the holiday intern presented the results and the outcome to the main stakeholders. In this presentation, the proof of concepts results left stakeholders very impressed, even initially skeptical product managers. We have 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 Testaton 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 the question. It was a journey that began then.

Rudolf Groetz

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 with goals, the goal the testing scope within project. This can be a module, a component, or a feature of the system under test, goals help you organize your tests logically, we have goals for features. As an example, we have goals to test our crud functions or our workflows, and many others. The test for the crud 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 our 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 rich editor or the standard editor. We have test plans. We manage the execution of test goals. Test plans allowing it was scheduled execution of a specific set of tests with use 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 build gets to be use that defined in a test data table. If you 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 concerns 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. Supply evaluations, compliance assessment, and security audits. Currently, we are just about to closing the license bank. Next to 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 tests 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 low code test automation bandwagon. Here you can see, there was a change of heart by many test automation stakeholders.

Rudolf Groetz

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 passion, 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. He said like this change of heart. 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.

Intro / sponsor read

Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in 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.

Intro / sponsor read

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 at TestGuild.com where you become part of our elite circle driving innovation, 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 TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

Intro / sponsor read

Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild Automation 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 testers, showing them the secrets to behold.