Journey Unleashing the Power of Robot Framework with Elisabeth Hendrickson

But then I realized that maybe it would make more sense to start my story with hello world, with the point of time when I first actually put my hands on robot framework. As long as there's been software development, there's been software test automation. Jerry Weinberg used to talk about doing test driven development on the Mercury Project way back in the day, so. But I could start my story at the beginning.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, welcome to another episode of the Test Guild Automation Podcast. In today's episode, I have the pleasure of sharing a presentation from Elizabeth Hendrickson, who is a renowned speaker, expert in test automation and development and author of the top rated book Explore It, Reduce Risk and Increase Confidence with Exploratory Testing. I've actually been trying to get Elizabeth on this show since 2014 without any luck, But I hosted an online event called RoboCon a few years ago where Elizabeth was the keynote speaker and thought now is my chance to at least create an episode featuring her by reusing her session here. Elizabeth's keynote speech was titled Robot Framework through the Lens of History, which takes you on a fascinating journey through the evolution of test automation, where she highlights some lessons learned, some stories and influential figures she met along the way. And as she delves into her archive, she discovered long lost gems that shed light on the frustrations and challenges she accounted on her test automation journey. From the frustration caused by heavyweight software development processes to issues with test automation tools. Breaking and providing irrelevant information, Elizabeth takes us through the hurdles she's faced, triumphs, and shares the history of test frameworks, including Robot Framework along the way. You don't want to miss it. Listen up. Also, if you have anything to do with the robot framework, this is a excellent time to check out and register for RoboCon 2024. They're gonna have both an in person and an online version that I'll be hosting, so head on over to robocon IO register and hope to see you there.

This episode of the Test Guild Automation Podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to your brand awareness, lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us, from boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild can take your brand to the next level. Head over to testguild.info and let's talk.

Hi, my name is Elizabeth Hendrickson. So we're here today to talk about robot framework through the lens of history. When Peka approached me to do this talk, I thought that it would be a really lovely opportunity to revisit 25 years or so of my personal history, my professional history.

It was, it was a lot of fun to go through my archives and dig stuff up that, honestly, some of the stuff I dug up, I thought I'd lost long ago.

More importantly, I thought it was a good opportunity to highlight some history that maybe not everybody would know about people and events that were really influential in getting our industry to where it is today.

So then the question was, well, where, where should I start the story? I. I could tell a nice linear story. 25 years of history begin at my beginning, which obviously isn't the beginning of test automation.

In general. My history only with test automation only really goes back to about 1995, 96, something.

And the industry has been around a lot longer than that. And as long as there's been software development, there's been software, test automation. Jerry Weinberg used to talk about doing test driven development on the Mercury Project way back in the day. So. But I could start my story at the beginning.

But then I realized that maybe it would make more sense to start my story with hello world, with the point of time when I first actually put my hands on robot framework. So I take you back to a bar. The year is 2007. It is October 2007, and the place is Portland, Oregon. More specifically, McMenamins Kennedy School. This is the site of the very first Agile Alliance Functional Testing Tools workshop. We'll talk more about those workshops in a bit. But we were all gathered there. Peka was there, Juha was there, I was there. We were all there for the workshop. And we had agreed that as long as we were all in the same place together, that we would take this opportunity to work together to get my laptop set up to run robot framework. Now, at the time, Robot Framework was not open sourced. That wouldn't happen until 2008. However, we were all working for the same, doing some work for the same company. And I was teaching classes and running workshops within the company. And although I was not going to be teaching robot Framework, there was a general agreement that the more I knew about the test automation framework that was being used, the better I would be able to bring that context into what I was doing with the company. So this was something that we all agreed was a good idea for the company. I also honestly was kind of excited to learn Robot Framework. However, it had been a very busy past few days, and we had not had a chance to work together. And at this point, we were all kind of in a celebratory mood at the bar, and I was two beers in, and when Pekka came over and said, so, when are we gonna pair? I had to say, I think this is just one thing that's not gonna happen. We're not gonna have time because, you know, we're all enjoying the party now. And.

I should have known Pekka could.

Be very driven. And so he said, no, no, we have time. We have time now. I'll get you another beer. You get out your laptop. So that's how I found myself at the bar, pairing with Pekka. And I. I think pairing with Pekka, it might have been with you. How about getting Robot Framework set up on my laptop, beer in hand, and writing my first hello world Framework? And of course, as time went by, I really genuinely learned to appreciate so much about the design of Robot Framework. Just from the very beginning, the concept of the architecture was absolutely incredible. And we'll talk about how.

The influence of these workshops, I think, contributed to the. The tremendous.

Framework and community that Robot Framework now has. So, however, to put all of this in context, we do need to go back in time to a very, very different time in our industry's history. Flashback to 1996. Behold, a cubicle from 96. This is not actually my cubic.

I don't have a picture of the office that I was in at the time. I found this one online, and honestly, I had such a flash of recognition because even the color of the panels, I think, is the same as the furniture that we had at the office that I was in.

So the same desk, same everything. This was basically what my cubicle looked like at the time. This was in a software company, relatively small startup, scrappy little startup that made enterprise software. We had what was at the time, a very typical software development process. We were doing major annual releases. We had a completely separate QA organization that had a reporting structure completely separate from development. So the head of development and the head of QA were essentially peers in the organization, and we followed what we believe to be best practices with respect to our quality assurance process.

As was true with many companies at that time, though, we did have a pretty big problem, which was that there was an overwhelming amount of stuff to test. We were operating mostly manually. Vast majority of what we did was manual test script execution. And it took weeks and weeks and weeks and weeks to qualify any release. And of course during that time we're finding bugs and so we're all playing whack a bug and schedules would get blown out. It was, it was the usual kinds of terrible stories that you hear.

And ultimately we did decide that test automation would be a way that we could potentially address the combinatoric explosion problem. Now what I mean by that is our architecture was at the time dubbed a client server open architecture. And what that meant was that we had a thick client that ran on a machine like a PC or a Macintosh. I believe that we supported Mac, DOS and Windows at the time. And it would have been Windows 95 I think anyway.

So we had these clients, we had to test all the clients. But then at the back, back end we could support any of a number of major databases, database flavors, Sybase, Oracle, I forget what else. Plus we supported major networks like Banyan, Vines and Novell and I don't remember anyway, when you mapped it all out, it was basically this combinatorics problem of the Win95 client with the Sybase database and this driver and that network. And it was, it was huge. Even if we did some analysis and determined, well, these two things don't actually affect each other. So we just have to make sure that we test it just once, we still ended up with a massive matrix of all of the combinations that we had to test. And that was just the combinations that that wasn't the tests themselves. Then we also had to like actually execute all of those tests. And since we were doing the same tests over and over and over again, we did decide that test automation would probably help. And this is how I found myself as the team lead for the test automation team. And there were, I believe, four of us. Now here's the thing about the state of the world with respect to test automation at that time.

The typical way that you would do this is to purchase one of the various tools that were on the market. There were a bunch of them and all the tools basically made the same promises. We did try a couple of different ones. It doesn't matter which ones we tried because the key thing is that they were all vendors tools that were expensive, that had a hamstrung vendor script language as the programming language for the thing. But the theory was that you wouldn't have to do very much of that because you were going to record and playback. That was the theory. And so all of the vendors in this space were pretty much promising magic. They were pitching their product as something that was so easy to use it could be used by non technical people. And by the way, I absolutely loathe it when, when anyone describes people by what they aren't as opposed to what they are. But that was still, that was how this was pitched. That you could have relatively low, low skilled group of QA people who would be able to take these tools and get test automation for free as a side effect of doing their normal testing stuff and just recording as they went. This of course didn't work. We figured out fairly quickly that was not gonna work and that test automation was programming. But we still had a very small number of people who had licenses because the licenses were so expensive. So I think we had four people doing test automation. So we had four, maybe five licenses. Because the thing that you can't see in this picture, you have to picture what would have been behind me if this is where I sat in my cubic, behind me was a folding table that had a bunch of computers lined up. Because remember this is 1996. So the cloud was not a thing, virtualization was not a thing. In order to run the test automation, we needed actual physical computers to run it on. And if you left the monitor actually like turned on, you would see it took over your computer and so you would see the windows flashing and the data getting entered very, very fast. It was actually very exciting and somewhat entertaining to watch. In fact, it was side note, so exciting and so entertaining to watch that it became a tour stop on the CEO's regular prospect customer prospect tours. He'd come by, he, he loved to tour prospective customers around the building to see the different groups work. He would take them to the developers area and they would get to watch the developers work. And then he would take them to various other areas, to the QA area, get to watch the QA test people test. And on one such visit, he saw these things happening in the test automation lab, which again, folding tables right behind my cubicle and I got to give a little song and dance and he got to talk about how much we invested in quality. Very impressive to prospective customers. The thing about being a small, scrappy startup though, is that you typically are looking to save money wherever you can. And in this particular case, one of the places where the company sought to save money was on not buying too much equipment. And so consequently, as we grew as a company and we hired more QA people, we would put in the requisitions for hey, let's buy another computer because new person's starting. And on too many occasions we were told, no, no, you have plenty of computers. Figure it out, make it work. And so of course we were pilfering from the test automation lab, which incidentally we had pilfered from various places, older computers that weren't being used to fill up the lab. So it's not unusual in our, in this case, it was not unusual for machines to get pilfered. So we were pilfering started with four machines, then three machines and then two machines. And it probably was on the day that, that I had taken the last machine out of the lab and handed it off to an UQA person who started that. The CEO came by with his little tour group to show off the test automation lab and the investment we make in it made, we're making in quality. He turned to me and he said, where are the machines? What did you do? And it was all I could do to keep from saying to him, hey, you know those purchase orders you wouldn't sign? Guess what? I didn't do that though. These were customers and that would not have been the done thing. So I don't remember exactly what I said or exactly what I did, but I probably gave a demo on my machine of the things moving very quickly and entertainingly. In any case, I digress. So this was the state of The World in 96 Heavyweight software development processes, heavyweight test automation tools. And honestly, while we had some success, there was a lot of frustration that just so often when the test automation broke, it had nothing to do with the software under test. Or at least it wasn't telling us anything interesting about the software under test. It was the maintenance burden of fragile test automation. They took a long time to run, they weren't providing good information, they required a massive investment and there was such a long feedback loop that the developers would change stuff and not even realize that they were breaking the test automation because we couldn't afford to buy licenses for them so that they could run the automated tests. And so the, the it just became untenable. And honestly, while we had some successes, I would not overall say that we were wildly successful. And I ended up very frustrated and jaded and cynical. It was at about this time that what I didn't know was that there was a whole rebellion brewing. So I found out about this though. In 1997 I went to a conference and I accidentally met up with chem kaner. I, I didn't know who he was at the Time I, I, we were both filing out of a plenary session and we were closely proximate to each other and he struck up a conversation with me. I did ask him later why, why me? Of all the people like why, why talk to me? And he said oh well, I was really curious because that session was so awful but you were scribbling notes frantically. I wanted to know what you got out of the session that I didn't. And of course I had to admit to him that what I was doing was because I was trapped in this seat and in this large audience there was no good way out. And I was listening to this thing that made me so angry. I was taking notes on everything that made me angry as my way of dealing with being in this situation. So I did tell him that I no longer remember what the topic of the talk was or who was speaking or why I was angry, but it was, it led to that great accidental meeting with Chem Kaner. And as he and I were talking about our experiences in the industry we kind of bonded and he, we talked about test automation. He shared with me that there had been a group of people he said that's funny. Group that just met a few months ago to talk about frustrations with vendors and.

Vendors that over PROMISE and tools that under deliver and share experiences to get beyond the vendor height. Well, what I didn't know at the time was that was the first, the very first Los Altos workshop on software testing. And he also shared forwarded to me a couple of papers that had come out of that. One of those was his paper on maintainable test automation where he explicitly called out that test automation is programming. And James Box.

Incredibly well written.

Test automation Snake Oil paper. It was a little bit more incendiary than Chem Kaner's paper but laid out such incredibly insightful points about why the vendor hype just the tools do not live up to the promise. So as I read these I realized I found my people and I ended up becoming involved in the LOST Los Altos workshop on software testing. There were, I don't know, I think 17 or 18 meetings of lost. I did love the joke Lost weekends we held them on weekends.

They all had roughly the same format, although certainly the exact details evolved over time as we collectively got better and better and better at the format for these meetings. The basic structure remained consistent in that it was a relatively small group of people, 12 to 18 people, give or take, small enough that you could have incredibly deep conversations. It wasn't a conference in the sense that there's a speaker and there's tracks. It was instead entirely peer driven and grounded in experience reports. And so the general format would be somebody would give an experience report and the rest of the folks would ask questions and challenge their thinking and challenge each other and have a discussion and extract absolutely as much insight as possible out of that person's experience. And then somebody else would go and do an experience report. One of the things that made the format utterly brilliant and that Kem Kaner absolutely deserves 100% credit for, was the intellectual property agreements for the material that came out of those workshops. It explicitly says in the handbook that there's no official minutes that come out of these meetings. There's no official record. Instead anybody who's there is welcome to publish whatever they would like. There are rules for attribution. You know, if you're talking about someone else's invention, you don't ever claim it as your own. And if you talk about what happened at the meeting, you have to cite everybody who was at the meeting.

But the explicit rules actively encouraged publishing because part of the whole idea was to distill as much insight as possible in these group settings. And so a lot of conference talks and articles and papers came out of LOST meetings. It wasn't just Lost though. The thing is, LOST was such an absolutely brilliant structure, gave rise to a bunch more, kind of like Lost, each with its own particular quirks or ways of operating, but with that same sense of relatively small group of people, incredible conversations, and huge amounts of insight and knowledge and publication coming out of it. This community does, does love some acronyms. So they're all acronyms. Whopper is the Workshop on Performance and Reliability. Steamer the Software Test Manager's Roundtable. WET is the Workshop on Heuristics and Exploratory Testing. LUTE is the London Exploratory Workshop on Testing. And otta. OTTA has a very special place in this story. OTTA is the Austin Workshop on Test Automation. But the key thing is that this rich set of incredible peer driven conferences allowed for so much knowledge sharing. It really advanced the state of the industry at the time. And I'm sure that there are more that either I am not aware of or that I am forgetting to mention. LOSS really did spawn an incredible number of similar kinds of community events. All right, so that was the rebellion. But now let's talk about kind of what happened next in the industry. The rise of oss, Open source tools. A couple things were happening at the same time. So this is in the early 2000s. One thing that was happening was the rise of agile. So the Agile Manifesto was published in 2001. It was not the beginning of Agile. Some people kind of point to it and say, well that was the beginning. Actually the beginning. The beginning had been brewing for frankly years, years and years. And there's a long history that involves the patterns community and the small talk community and various other communities that contributed to the place where we kind of might look at and say, well, that's the start of Agile. The Agile Manifesto had brought together a group of people who at the time were practicing lightweight software development approaches that flew in the face of those best practices that we had been using in 1996. And the end result of that gathering at Snowbird was the Agile Manifesto, a distillation of very high level principles that defined what Agile was contrasted with what at the time was considered best practice.

Agile really gained traction from that point forward, from 2001 forward. And with that it created a different context in which the very heavyweight specialized commercial vendor tools didn't frankly make as much sense. In a world where instead of a separation, strict separation of QA and development and instead co located cross functional teams that have all the skills that you need to release software. Having specialized tools that only a small percentage of the people on that team would be able to have access to or know how to use no longer made sense. Furthermore, programmers were frankly getting a lot more into finding ways to automate tests than perhaps they had been doing in 1996. So I think it's important to note that developers have always tested and anybody who thinks that developers don't test, that's just flat out not true. But what was true was that there wasn't a whole lot of test frameworks available for the popular languages of the day that made it easy to write tests. But that started changing with, I believe it was 1999 when Kent Beck came out with Junit.

And the various X unit family of unit testing tools. They're grounded back in and S unit days, but they still were massive leaps and bounds forward for unit testing for developers. So on these Agile teams now you've got tools that are designed to make it easy for developers to write tests and so the, the dynamics start to shift. Furthermore, when you've got these integrated teams.

Having ways of tightly.

Bringing together the code that's going to drive the application and the expression of the expectations that that became all the more important. And we start to see that with fit word Cunningham came out with fit in 2003.

And fitness followed closely After.

So with Fit you would have your HTML file with T that had an expression of.

Natural language expectations and then that would connect with fixtures to code that would would talk to or drive the underlying application code. And Fitness did that. But with Wiki. Kind of ironic that the person who invented wiki anyway doesn't matter.

You also are seeing.

Water and Selenium drivers for web applications. And then Cucumber had a different approach than Fit. Same idea of being able to express expectations in natural language. However, instead of tabular being able to express in terms of given condition, when event.

Then expectation, it was a different way of expressing ideas. And so we start to see these tools that are really designed around encouraging collaboration, designed around the idea of blended teams and tight feedback loops.

And there are so many other tools that were all exploding at the same time. It was a Cambrian explosion of tools in the early 2000s. Absolutely amazing explosion of tools.

Now I mentioned OTTER plays a special role in this. So the Austin Workshop on Test Automation.

The person who started it, Brett Petticord, he's one of the people who created water web web testing in Ruby. He had been partnering closely oh, here's chemkaner. So Chem Kaner created Lost and Brett had been partnering closely with Brian Marin who had been really promoting Ruby as a test, a language for testers, scripting language for testers. And so Brett and Brian had a class that they created and I believe that water had come out of work that they had done in the class, contributions from many other people. But Autumn became a place where we could talk about things like.

Water or so it was a little bit more from the, the tester community.

There was at the time this really interesting kind of thing happening with the Agile community and the context driven test community. And so this was more likely to be from that perspective of testers. But testers like pure, straight up separate QA kinds of testers, that's not the culture that we had here. Instead it was a bringing together of people, like minded people from all different perspectives from the perspective of testing and from the perspective of development. And so you see Ward Cunningham here at Otta 4. So the Austin Workshop on Test Automation, much like Lost before it really created this place for an incredible sharing of knowledge and perspectives that led to.

Amazing steps forward, innovation, tool adoption. It also led to. Oh, and Ryan Wilcox by the way worked for ThoughtWorks at the time. He did what I first time I ever saw selenium demoed at water6 or sorry at OTA6.

It was a place for people to Come together and talk about tools. Rob me had joined OTA number four to talk about domain specific languages.

He was the founder of Pivotal Labs. It was not yet called Pivotal Labs, but the company existed and that ended up being a professional connection that had a massive impact on my career personally. And so these workshops became places where not just shared knowledge, but also ended up affecting people's careers rather drastically. I ended up doing a few contracts for Pivotal Labs and then ultimately eventually joined Pivotal Labs full time right before it was spun out as the company Pivotal. And I spent seven years there. So all of that came about thanks to one particular autumn meeting. Anyway.

So ADA had had given me this, this perspective on.

Workshops for sharing information about tools, for doing demos and having and talking about trade offs and approaches to doing things.

The next thing though, that brings us to the Agile Alliance Functional Testing Tools group, which is really, I think, what when Peka asked me to do this talk, he was thinking about how influential that program was. It was not a long lived program. I think we had a total of maybe five meetings.

But it had a huge impact for such a small program.

And it's worth talking about how it came to be. Janita Andrea is the reason that the Agile Alliance Functional Testing Tools program existed and she's the reason that it got funding and she deserves all of the credit for its existence. She had a vision and she talked to me about the vision. She noted that in the industry, IDES had come so far in 10 years. It was incredible. As a programmer, you now had automated support for massive refactorings. You had intellisense.

With command completion and incredible, incredible tools at your fingertips. And when it came to test automation with things like FIT or any of a number of other tools, cucumber, the, the tooling was incredible, but you still were expressing expectations in natural language. And there was no tool that really did a good job of making that connection between the expression of intent and the underlying code. And she recognized this as a severe limitation. It resulted in it being so much more difficult for a business analyst to edit the expectations directly.

And she believed that.

Things could be better and she had a vision for that future. And then the question is, well, how to achieve that. And so as we talked and I reflected on my own experience with Lost and with ada, I suggested, well, there are a lot of toolmakers and what if we got them all together and had really deep, rich conversations about the state of tools and what we wish were true? So bringing together not just toolmakers but also tool the people who would benefit from the tools. And we started with one workshop, so we got funding because it was an Agile alliance funded program and we used that funding to provide travel stipends to make it possible for people to attend. And.

We.

Brought together a bunch of folks in Portland, Oregon in October 2007, which is why I ended up in that bar, two beers in and pairing on Robot Framework. But during that first meeting we had all these people sharing their perspectives. Let's look at who was there. Of course there was Janita.

And here's Pekka Clark, who of course you're going to recognize. And I believe that's Juhai. It's a little hard to tell because, because the picture is so grainy, but I'm pretty sure that that's Yuhua. Here's Ward Cunningham and Brian Merrick and here's somebody. You might not know how Sauce Labs came about, but John Dunham at the time, serial entrepreneur, not necessarily really steeped in the test automation space, but very committed to the idea that open source was definitely going to be his next thing. He was going to do something in the open source. And absolutely intrigued by what was going on, he came and although he did not meet his co founders at this meeting, I believe.

It was through the connections through this community that led to the founding of SAS Labs. Another example of these kinds of workshops leading to fairly big change. Here's another one. So this was at the second meeting in Toronto and Andrew Clay Shaffer.

He was there now, funny story. So I later met up with Andrew Clayshaefer at, I thought I was meeting him for the first time at a DevOps conference. He gave a talk that I thought was utterly brilliant and I stayed to talk to him about it. And he said, oh, you and I have met, we what now? He said, oh, you might not remember, but I was at that AAFT meeting in Toronto. I stumbled in.

Stumbled on it, hadn't planned to be there, but I, I remember asking you, would this be the place to find people who would be interested in test driving infrastructure, test driving, the state of virtual machines? He was at the time, he was at Puppet Labs, he was one of the co founders of Puppet Labs and he, I did remember when, after he said that, I remembered the conversation even though I didn't remember having met him before. And I remember saying, well, I don't know, but if there is anywhere here that you're going to find somebody interested in that, it's probably in this room. Come on in.

So overall, five meetings. The third meeting I don't have good Pictures from But that meeting I think was probably particularly influential as La Calasoi came. And I remember that there were fantastic conversations about capabilities that Robot Framework had and that Cucumber had and that fit had. And the end result was saw this really interesting after that ratcheting of capabilities Robot Framework got given when then syntax. And I know that there were changes that went into Cucumber as a framework. And so it was through this incredible opportunity for people to come together and share their experiences, their ideas, their implementations and that we saw such incredible growth in the capabilities of tools. At the time.

I did say I would tell you why I think Robot Framework is genius. So if we go back to the that time in the bar where I was writing my first hello World script, I could already see that there was so much there that I was really going to appreciate. And over the next several years I used Robot Framework a lot.

I think that probably the best illustration of the power of Robot Framework is in some work that I did for a company where there was an API and a command line interface and a web interface and they needed to have automated regression tests. And I recognized an opportunity to express the expectations once, because the expectations it was a service that you put stuff in, you got stuff to out. And what you put in and what you got out should be the same regardless of whether you get that by curling an API endpoint or by clicking through a browser. The input, if you give it this input, you should get this output. And the thing about a tool like Robot Framework is that you can eliminate all of the incidental stuff that doesn't matter and distill out what really, really, really matters in terms of expectations. So you don't put in all of the click steps, you can extract all of that out and just express. If I put in this, I get out that. So I did. And we had one page that had the regression tests for the most important. If nothing else works, these things should be true that then you could control execution for which of the different plugins.

Actually executed the test at execution time. We had one artifact that represented the expectations and then configuration to point it at the correct thing with the pluggable architecture for the various plugins that would drive the appropriate interface. That.

Capability is so far from anything that I could have imagined in 1996. It was utterly amazing, provided a huge amount of value for this particular company and illustrates the things that I love most about Robot Framework. So being able to express expectations in natural language is so incredibly powerful and it allows us to think about the Essence of what we're building as opposed to the implementation details. Separating the expectations from the implementation details, separating the what from the how, has so much incredible power. And the fact that robot framework is flexible in how you express those expectations. There are some systems that lend themselves to very strict tabular formats and there are others that lend themselves better to what Dale Emery would call a planned response system. Where you've got given this condition when event than expectation.

There'S systems that just lend themselves so much better to that kind of expression.

The wealth of plugins that allow you to test heterogeneous distributed system.

Make it incredibly powerful and adaptive for such a wide variety of systems. And then the third thing that I love about robot framework is the control of execution. The fact that you can tag your tests. And these days, back in 1996, we didn't have a build pipeline, we had a build, but there was no pipeline. There was build and then a QA phase. These days it's very different. It's much more common now. Have an entire pipeline where starts with a build and then some functional tests. But then there's probably a fan out that has a bunch of configurations or a bunch of platforms.

And so being able to have the same set of tests that are all.

Under source control in the same repository as the code, and that you can control which thing is executing it, when, which place, depending on tags, makes this an incredibly flexible framework for with respect to controlling execution. So these are primitives, these are building blocks that make robot framework incredibly adaptable.

And.

Just frankly so, so many light years beyond where we were in 1996. And I hope that it's been valuable to you to hear about that entire journey as an industry that we've taken from that time to get to where we are now. Now what I find really interesting is looking ahead.

Here we are in 2021 and the industry's changed so much in 25 years. And in some ways I almost feel like now we're kind of back to the future future.

A really interesting thing is happening with the emphasis on low code tools and low code test automation. And we are at a fundamentally different place than we were in 96. And so I don't necessarily view this as the pendulum of history. Low code, lots of code. Low code, lots of code. It's more like the spiral. And we're now in a fundamentally different context. And I think that it's going to be a really interesting adventure to see how robot framework and the community learns and grows and adapts given today's modern application development approaches and the new emphasis on low code things. This is going to be absolutely fascinating. Anyway, I think it's time for some question and answer and thank you so much for your time.

Thanks again Elizabeth for your automation awesomeness. Links of everything of value we covered in this episode. Head on over to test guild.com a467 so that's it for this episode of the Test Guild Automation Podcast. Once again, I'm Joe. My mission is to help you succeed in creating end to end full stack Automation Awesomeness. As always, test our attention and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or software a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.