Hans Buwalda - CTO at LogiGear

(Intro Narrator at 00:00:00) I highly recommend the book The Third Wave by the cofounder of AOL and now billionaire Steve Case. One of my favorite parts from this book is when he said it took AOL having the potential to be the first trillion-dollar company to losing over $200 billion in value to learn how important the people factor is. He goes on to share a moment when speaking on a panel with the CEO of Siemens, which employs 50,000 engineers. And this CEO said the key to surviving is having an ownership culture. You have to get into people's hearts, and you have to get to where people's prides are.

(Intro Narrator at 00:00:39) So now this is important because this is exactly what the foundation of the Leaderbits leadership program is built upon. If you want your technology leaders to go from good to great, visit leaderbits.io. Today we are talking to Hans, the CTO of LogiGear, and we discuss the benefits of testing and getting people excited for it, becoming a change agent to drive innovation, and listening to the market to provide value to the customer. All of this right here, right now on the Modern CTO podcast.

(Joel Beasley at 00:01:13) Here we go.

(Intro Narrator at 00:01:14) This is the Modern CTO podcast.

(Joel Beasley at 00:01:25) So I was very excited to be speaking to you today because you're like the godfather of testing.

(Hans at 00:01:33) Yeah, maybe pioneer of automated testing. I think that is probably the most accurate. The way I always explain it when I do something like a tutorial is I'm a lazy person. That's why I'm in automation.

(Joel Beasley at 00:01:49) I like it. How did you originally get into technology? Like, how did you fall in love with technology, and then how did that translate into you ultimately ending up in testing?

(Hans at 00:02:01) Yeah, that's a bumpy ride, or more of a roller coaster is the better word. I'm interested in computers already since high school years. There was already a television course in, like, 12 lessons or something about how to manage the computer, and I followed it as a, like, 15-year-old.

(Hans at 00:02:25) And then when I went into university, I initially started mathematics, which I did till bachelor. But then there was an opportunity to do what I call informatics and computer science, which I took, and that gradually became my major subject, and mathematics kind of vaporized. And yeah, then after finishing study, I went to work for a big European company in computer services, but I ended up in the management consultancy department. So instead of being technical, I was also, multi, management consultant for about 10 years, which was my minor during my student years. So I took a lot of classes that had to do with leadership and management and that kind of stuff and even accountancy and law, all kinds of things that were not necessarily part of a mathematics or computer science package. It turned out to be very handy later on.

(Hans at 00:03:28) So the first 10 years of my career, I've been doing very generic management consultancy without any programming or anything involved. And then I ended up in an assignment for the Amsterdam Stock Exchange. They were working on a new screen trading system. They had always floor trade. The Amsterdam Stock Exchange, by the way, is the oldest stock exchange in the world.

(Joel Beasley at 00:03:54) Really?

(Hans at 00:03:55) Yeah, that really dates back from the 17th century, and they basically had never changed their ways. And now suddenly they make a big move to screen trade, so that's a big revolution. And about three months before the system would be put in production, they really found out that they didn't have any decent testing. They had tried to do some automation that had failed, and I was hired as a bit of a troubleshooter to do something about it.

(Hans at 00:04:26) It was not necessarily a technical assignment. It was more like get departments to work together and work with the external auditors from KPMG and the internal auditors, try to make it work. And that's when I kind of discovered automation, test automation, came up with a keyword-based approach called what we now call action-based testing. And yeah, whether I liked it or not, I've been doing that ever since. So it was not a deliberate career choice, but it also brought me back a bit in technology, which basically after 10 years I had not done much about.

(Joel Beasley at 00:05:09) And then at what point did you cofound LogiGear? Did you cofound that?

(Hans at 00:05:15) No, they were around already. It was cofounded by Michael Hackett and Hung Nguyen. Hung Nguyen particularly being a very major, a very major authority in our market. He wrote, co-wrote, the book Testing Computer Software with Cem Kaner, which is the best-selling book in software testing, or at least at the time it was, and I think it still is.

(Hans at 00:05:41) And so based on that success of that book and thinking about the philosophy, he and Michael Hackett founded the company. I don't remember exactly what year, but a couple of years later I joined. And by joining, I brought it more into automated testing. Up to then, it was all about manual testing. And since I joined, we diversified. We still do a lot of manual testing too, but we diversified into automation.

(Joel Beasley at 00:06:13) And how large is that company? Like, how many engineers do you have?

(Hans at 00:06:18) Well, in the U.S., it's about, I think it's somewhere in the thirties. I don't know the exact number. But we have a much bigger operation in Vietnam where we have about, I think it's about 600 or 700 people. It fluctuates a bit, mostly in Ho Chi Minh City, but also fairly large part in Da Nang, which is in the middle of Vietnam.

(Joel Beasley at 00:06:45) And the primary driver of that business is you have clients that you test for?

(Hans at 00:06:52) Yeah, it's a bit all over the place. Testing is very diversified. That's also the reason I stayed in testing. It's a very, very fascinating, very interesting industry to be in.

(Hans at 00:07:04) It is much more interesting than you would think. It is usually seen as like a chore. You have to do it. Maybe you can fit it into a sprint or something, kind of get rid of it. But it actually, if you try to do it more seriously, testing and particularly automated testing is a very interesting challenge because you will need to develop software that talks to other software, and that's always challenging.

(Joel Beasley at 00:07:32) Yeah, I don't consider it an option. It's part of shippable code. You write tests.

(Hans at 00:07:40) Absolutely, yeah. Sometimes I wish it was an option because then people would be more motivated. Now it's really seen as a chore. You have to do it.

(Joel Beasley at 00:07:49) I don't see it as a chore. I see it as something that gives me—look, I'm a big fan of testing because I didn't test for so long. I'd say I've been writing code for 15 years. Well, now it's been, like, I've got to stop saying that.

(Joel Beasley at 00:08:02) But I've been writing code for 17 years now, and I'd say for the first seven or eight years, no test, nothing. Then I found out about testing, and I went through this awkward stage where, like, I kind of tried it but I kind of didn't. And in that time, I figured out, like, how much time—when you know how to do it right and you set your tools up and you have a clean workspace and everything's good, when you're testing correctly, it speeds you up. You don't have to guess. You put code in place, and then you put other code in place to make sure that's running. And then if it's ever not running as you intended, you get notified of that. That's like a huge feature. It's a massive benefit.

(Hans at 00:08:42) To get there, you went through a learning curve. It was not like, okay, uh, Daddy, what am I going to do in the future? I'm going to be a tester.

(Hans at 00:08:53) It doesn't work that way. You're a coder, and you like computers, and you like programming, and you like it to work. And, oh no, if it doesn't work, it doesn't work. Then you discover, hey, there's such a thing as testing. And if I do that systematically, if you really approach it as a different method, if an approach, and I think about it, the little grey cells are somewhat dedicated to it, then it starts working and it starts to improve the whole process. And that is very strongly now with CI/CD. You really see that it's all about testing. If you want to make it successful, okay, there is configuration management, there is, and you need to set up the pipeline. But as far as I see it, that's fairly straightforward. You select your tools, and there are, like, tools on top of tools, and there's a lot of stuff. It's already available. And if you go into it, it will be okay. Testing is a whole different story. You have to test all kinds of different configurations. You encounter unexpected things. It is, it's a much more interesting—I don't want to call it challenging, but interesting field now we have the CI/CD.

(Joel Beasley at 00:10:12) I love, for me, and I'm not super deep with it as of today, but for me, the CI/CD was awesome because now it just kind of took a bunch of steps and just made it really simple. But I found different tests at different times. And then, like, learning, like, an instrument, you become better at it the more you do it, right?

(Joel Beasley at 00:10:38) And then there's different—and then, like, you over-test, and then you realize, like, what's the appropriate amount of testing and how to test better. And then you get into the weird situations where you're, like, working with different, like, libraries, and you have to overcome—like, in my head right now, I was just thinking about when I figured out how to overcome some of the, like, AJAX issues that I was having initially testing, and this was probably seven years ago or something. But we have, like, headless browsers, and then you have to actually boot up a browser with a head to test some of the certain things. And then there's all the different people and all the different stubs, mocks, spies. You get all the different ways to structure it and all the different terminology, and then you finally figure it out, I guess, after just a lot of persistence. Figure out the right cadence for you and the project.

(Hans at 00:11:26) You will find that if you're comfortable with the testing and particularly the automated testing, you're also going to be comfortable with the rest of the project.

(Joel Beasley at 00:11:35) It gives you certainty.

(Hans at 00:11:37) Yep.

(Joel Beasley at 00:11:38) Yeah.

(Hans at 00:11:41) And the way I position it often is, like, it improves your quality to market. It improves your time to market because you can quickly make changes to your system because you can test it, and you can test everything all the time. All the time makes you, gives you enormous power. And then it also gives you control. It makes your process more manageable. It's more predictable. The quality is more predictable. You have less disruptions. And you see it, it's growing and growing and growing, the testing in it, in the amount of time that I spent in testing now, which is quite a while already. It is, it's getting more and more important, and more and more people are actually interested in it.

(Joel Beasley at 00:12:34) It is quite possibly the best—like, you should have seen me the day that I figured out that I was like a caveman who just created fire for the first time. I was so excited the day I figured out when we have a bug, we can then write a test against, like, the exact situation of the bug. And then now that's, like, never going to happen again. Like, that exact same scenario will never—and then it stacks, and then it stacks. Then as your application gets older, every bug you experience, you have a subsequent test. And then now you just, you don't have the issues anymore. Yeah, cool. It's amazing.

(Joel Beasley at 00:13:12) So you go around the world convincing people of this, or do you just find people who are convinced and help them do it better?

(Hans at 00:13:19) I think both. There are companies that are very new to testing. What you see is there is also a lot of people around that are non-technical and involved in testing, like domain experts and functional testers and people who really have done testing as a job. And that is like, they're a little bit under pressure right now because the testing, because of the whole automation, it becomes more an engineer's playing field. And that's not always right because what I learned in the ops, in the stock exchange when I was working there is the power of the domain expert.

(Hans at 00:14:05) People who really understand business, who really understand business situations. They can put a lot more pressure on the system and the test than if you are an engineer and you're new to the domain. And then you have to really—you can catch technical bugs fairly quickly, but bugs that have to do with unexpected situation, it's a bit harder. I always call that jungle testing. In my view, there are, like, two kinds of testing: testing against coding bugs, and you know what the system is supposed to do, but you need to make sure it really does that. And jungle bugs, which is like unexpected situations. So you're going through a jungle and stuff can jump on you, wants to eat you. And many of the bugs that make it into production are those kind of jungle bugs. And the best example of that is our own product, and it's called TestArchitect, which kind of supports that keyword-based action model. We often, because it's an automation tool, we often run into issues.

(Hans at 00:15:19) And when the tool meets kind of an unknown environment, you run into all kinds of problems. And so a large part of our testing is to kind of predict what those unexpected situations might be and try to write tests for them before it gets to a customer or to a project. And to answer an earlier question that you asked, what we do: we have our own testing services where we help, where we make test and automation for customers. And there are quite a few where the customer makes the test and we do the automation, and then also quite a few where we do the whole cycle. We do the test development and automation. And but we also do quite a bit of training and consultancy, go to customers, talk with them about testing, and try to suggest improvements.

(Joel Beasley at 00:16:11) I'm learning right now. I'm taking notes.

(Hans at 00:16:14) Okay, that's cool.

(Joel Beasley at 00:16:15) This is exciting for me. I just happen to be passionate about testing. Now, in my mind, when you were opening my mind to start thinking about the testing that I don't see—so for example, when you were speaking, for some reason I was thinking about, oh, I bet you there's testing, like, everywhere, right? And because my scope of testing has primarily been just applications that we're building for business logic, right? But when you were talking, I was thinking about, oh, when you're scaling infrastructure, when you're doing all of these other compute-related things, there's testing everywhere, right? That's just something I don't touch much. I was curious. One of my questions I had was, have you seen things, and I believe it's, like, Capybara is something in my world, but essentially where they'll take, like, a sentence of what it should do and associate that with a test.

(Hans at 00:17:13) You mean, like, a behavior-driven development, that kind of technique?

(Joel Beasley at 00:17:18) I'm not explaining it super well because it just popped into my mind and out of my mind. But maybe I'll send you an example after the call. But the concept is, they were tying sentences of what the user experience should be, and then having those sentences then run—they would associate keywords in those sentences with test, and it would build this.

(Hans at 00:17:43) Yeah, I kind of, I have heard about it. It's kind of a next generation of what is also called BDD.

(Joel Beasley at 00:17:51) BDD, there it is.

(Hans at 00:17:52) Development, but where BDD has at some point fixes the phrases that you use, I think Capybara really tries to do more an AI approach in which it really tries to analyze the sentences.

(Joel Beasley at 00:18:06) I meant, I meant Cucumber. That's what I meant. I got Capybara and Cucumber mixed. So, like, I just go—

(Hans at 00:18:13) Cucumber, okay, okay, then we're in the same space. Well, we have an, our approach is based on keywords.

(Hans at 00:18:24) So imagine a spreadsheet, and every row in the spreadsheet starts with what we call an action word, and then it has zero or more arguments. And we found that lots of people that are not technical have no problems with spreadsheets. Lots of domain experts really relate to that and start producing tests. And a large part of our method is not so much how can you make it prettier. The keywords are pretty enough.

(Hans at 00:18:52) It's not so much how can you make it prettier. It's more like how can you make the right kind of tests. And in that, we make a very strong distinction in higher level tests and lower level tests. And I'm saying it's a bit clunky, but that's what we do. And you organize your tests in something we call test modules, which are basically the spreadsheets, where each spreadsheet has a number of test cases, and all of them are written in that action-based format.

(Hans at 00:19:24) And you make a very strong distinction between the more business-oriented tests and, like, can I enter an order, and can I make a payment? Can I accept a credit card? That kind of stuff, which by telling you, you understand what I'm talking about. So if I make an action, enter order, you understand what that action does, but I have not shown you the system and the test. Could be an e-commerce, could be a car rental agency, could be anything.

(Hans at 00:19:57) You haven't seen, you don't know if it's in Java or C. You don't know whether you actually use a test tool and whether you're actually going to automate or not. Could be manual. But still, you understand the test, and still the test is fully automated because what you automate are those actions. And so an engineer does not have to worry about the business logic of the test case, can just focus on that automation part. And if he does a good job, that actually becomes reusable all around the test set. And then we call those the business tests, so you don't see anything about push a button or anything like that.

(Hans at 00:20:37) And then we have another category which we call the interaction tests, where you really focus on the UI, for example, or the API or whatever you're interested in, but you really test the hell out of it. So if you have a dialogue, you make sure that if you do the tab key that the cursor goes to the next field and that kind of test. So by organizing it that way, testers can basically lead, and it's all up to the testers. You prestructure it in these test modules. So this test module is going to test the financial part of our system, high level tests.

(Hans at 00:21:18) So you don't do anything else there. That's what you do. Those are the checks you will make. Those are the actions that you will make. And by prescribing that, it's like you have the table of contents of a book. You haven't written the book yet, but you know the chapters.

(Hans at 00:21:33) So now in a sprint, you're actually going to develop the test. It is not a problem for non-technical people to do that in a structured way because you already gave them the structure. It's like a closet with shelves. The labels are already on the shelf. The shelves are still empty. You're going to fill it up.

(Hans at 00:21:52) So by doing it in a systematic way, you basically get a very successful test and a very successful automation, which is kind of counterintuitive. When you think about automation, you think it's technical. It's a challenge for an engineer, but that's not the case. It's a challenge for the test design. The better structured the tests are, the easier it is to automate, easier to maintain.

(Hans at 00:22:16) Now back to the BDD. BDD does something similar with these phrases, but it is not really pre-designed usually in most projects, and they become messy. I actually had a discussion with Dan North. Dan North is the creator of BDD in one of those conferences talking about this topic. And I love BDD, so I told him. But he also acknowledged that problem that it is difficult to get it organized. Different people are coming up with different phrases, for example, and then you immediately need to jump to Cucumber and start programming to get it to work.

(Hans at 00:22:40) Now, so what I did is I made a converter. The converter goes from BDD sentences into actions, and it can also go back from actions back into BDD sentences. So that solves the problem completely. You still have that user-friendly format. But at the same time, you also have the actions which are much easier to manage and to organize. Even Dan North, who saw the product, even tweeted about it. And the idea is not so much the technical trick. It is more that you're basically following the same approach, but you can do it in a more systematic way because the more systematic you bring into your tests, the better the automation will be.

(Joel Beasley at 00:23:43) I love it. So you have a system with the tools, not just use the tool. Yeah.

(Intro Narrator at 00:23:49) Thank you for picking up on

(Joel Beasley at 00:23:51) what I was trying to remember because I did pull it up on my computer here, and it's like the Gherkin language and the BDD and the Cucumber. All those things came to mind. I don't know why my mind went to Capybara, but that's what came out, and at least we got that extremely valuable advice from you. I believe that there are some engineers, CTOs, engineering managers that are listening to this, and they're thinking, you know, I would love like, we haven't been as good as we could be on tests. We've pretty much done nothing, maybe the bare minimum. How do you change that culture, or what have you seen in your experience? Because you've worked with teams that didn't test. You've worked with teams that have tested, that love and hate it. What advice do you have in a team trying to change or improve?

(Hans at 00:24:42) Yeah. Yeah. I can give hard answers, or I can give soft answers.

(Joel Beasley at 00:24:45) Give the hard answers.

(Hans at 00:24:48) Hard answers. They're more direct. Yeah. I would probably prefer soft answers

(Joel Beasley at 00:24:54) Okay.

(Hans at 00:24:54) Because it is more about what the cycle that you went through yourself. Like, you start to learn about the benefits of testing. Testing is often seen as a chore, something you want to get rid of. That is even not so much for developers, maybe also for some developers, but it is also very much for managers. Managers, especially if they're not test managers, specialized test managers usually are okay.

(Hans at 00:25:23) But if it is an engineering manager who manages Agile, who manages the sprints and all that, that person does not have a testing background and will typically see testing as something. Yeah, you need to do it, but the energy is in the development and in the programming. And that is something that you should change first. There should be more energy behind the testing, and it should be more like, okay, if we can get that under control, we can get everything else under control.

(Joel Beasley at 00:25:56) Where is the book that sells testing? Like, there's lots of books that say this is how to test. This is about test. But where is the book that's, like, written by, like, half salesperson, half tester that's going to sell you on, like, all the benefits of testing. Does that book exist?

(Hans at 00:26:15) That's an excellent question. We have written some books ourselves. We take also kind of, we have written a book, Happy About Testing, I think it's called. You will find it on our website. That is a small book, which already is a big advantage.

(Hans at 00:26:36) That is a small book that is quick to read. It's actually, there is a recommendation from Steve Wozniak. You know Steve Wozniak? Yeah.

(Joel Beasley at 00:26:46) Yeah. How can you not know Steve the Woz? Yeah.

(Hans at 00:26:49) Yeah. Exactly. I recently saw him speak. He's very funny and very, very intelligent, very interesting person. But, Happy About Testing, I think it's called. Can you give me a second?

(Intro Narrator at 00:27:05) Yeah. For sure.

(Hans at 00:27:07) I'll run back to my desk.

(Joel Beasley at 00:27:09) Take your time.

(Hans at 00:27:10) Get it.

(Joel Beasley at 00:27:11) Okay. Yeah. Let's give a plug on this book. I'm excited about it. I don't think I've ever met anybody with as much love for testing as me.

(Hans at 00:27:23) Okay. Alright. Okay. You're still?

(Joel Beasley at 00:27:25) Yeah. I'm here. Yeah.

(Hans at 00:27:26) So, this is the book.

(Joel Beasley at 00:27:28) There it is. Happy About Global Software Test Automation. Nice.

(Hans at 00:27:35) Yep. So in here is that quote from Steve Wozniak.

(Joel Beasley at 00:27:38) Nice. I'll take a, I'll put a picture of, this is on Amazon. Right?

(Hans at 00:27:44) I'm sure it is. Otherwise, just send me an email. Oh, yeah. You see that, Hung Nguyen. Can you see his name?

(Joel Beasley at 00:27:50) Yeah.

(Hans at 00:27:52) That is the guy who basically founded the company together with Michael Hackett.

(Joel Beasley at 00:27:58) Very cool. And did you just meet them through your experience, conferences, speaking, things like that?

(Hans at 00:28:05) Yeah. What the book does, it also has a lot of executive input. So it really sells testing, and it really makes you happy.

(Joel Beasley at 00:28:17) Now, so we're working on a book over here, and it's about what I've learned speaking with some of the greatest technology leaders on the planet. So I did, you know, 230 interviews last year from CTOs, NASA, Microsoft, Verizon, like, just the whole from startup entry level engineer in their garage trying to do something cool all the way up to, well, Microsoft. And what I've done is I've taken, you know, all the different leadership lessons that we've learned from them, different advice that they have, and we're putting it all into this book this year. That's what we're working on.

(Joel Beasley at 00:28:55) And you mentioned that you had a background and you started out in leadership and management, things like that. So you obviously have that and your core experience, and you've gone all the way to CTO of this company, 600 plus people. What sort of, if you could wrap your career in, like, one piece of advice that's rung true over and over, what would that be?

(Hans at 00:29:20) I think for me, for my career, it is that combination between technology and management. So I think that is what you try to do even if you're a student nowadays and you figure out what am I going to study. I think for the technology, I would prefer to go deep. So that means really understand it. I have programmed in C++ a lot, not a little bit, a lot. I've programmed in .NET. Technically, I have the depth. I understand that. I've written compilers, operating systems. I know that stuff.

(Hans at 00:29:47) Combined with management, but then management also taking it seriously. So really not just, like, a little bit and process oriented, but really understand management, understand people, and understand processes. And what I like a lot is change, the management consultancy aspect of it and being the change agent, getting companies to go in a different direction. And that's what I like for myself. That is not to mean it's good for everybody, but you should always understand that when you embark on a technical career that you get outdated fairly quickly.

(Hans at 00:30:56) And during your career, you're going to find that there are new kids coming from school. They're all about AI, for example, and then you yourself might not be in AI that much. You need to catch up. But those kids were a lot cheaper than you. And so what's the point of you being there? And so you need to be planning ahead for that. I did. I realized that just programming wouldn't cut it. I was also programming languages like Pascal and Algol, and so you can imagine that's pretty old. And so you need to understand that you also need to be able to operate in a company or in an environment and that you need to be able to contribute, and that's not necessarily your technical skills. Does that make sense?

(Joel Beasley at 00:31:45) That makes 100% sense. Right? Because when I first started, I was very much about the accuracy of the very specific thing I was doing in the language I was in and knowing everything about that. And then you start to see the market shift and you realize, oh, if I know everything about PHP, like, that's not the only thing you need to know. Or if you know everything about Ruby or whatever, there's so much more to know, and then the industry just grows so rapidly.

(Joel Beasley at 00:32:12) And it's what I have found that it comes back to is, you know, relationships, you know, in data and in humans. Right? Like, you Yeah.

(Hans at 00:32:22) Yeah. Yeah.

(Joel Beasley at 00:32:23) The relationships matter, and you can't, I don't know. I guess one of my favorite quotes is, like, what will get you here won't get you there. Right? Like, you have to always be learning and paying attention and observing and watching. And then I love one of my favorite things that's popped into my head right now that I was thinking about over the past, you know, 20, 30 years in technology is that the rudeness became unpopular, and that was one of my favorite parts about our maturity as an industry. Like, the know-it-all, shoot you down, arrogant person used to be popular, and they became unpopular.

(Joel Beasley at 00:33:05) And in place of, like, a genuine, helpful person, and that was very exciting for me.

(Hans at 00:33:12) Yeah. I think so. But I have seen, in my style of consultancy and management, I'm, I think I'm friendly. You can ask anybody around me. I'm not like, rude or anything. But I have seen some rude people shake things up. That was with testing. There are some, some very direct people. Let's not call it rude. Let's call it direct.

(Hans at 00:33:38) There are some very direct people in our industry who have really got things moving. And it also happened with, for example, Agile. If you look at the original Agile, that was also, like, the values and, like, fighting and no, you're wrong and no, you're wrong. And but, of course, part of Agile is friendliness and politeness, and so that kind of takes over. But I've seen people being very aggressive about specifically about testing.

(Joel Beasley at 00:34:11) What is your day to day like at LogiGear?

(Hans at 00:34:16) Well, the answer you're probably going to get from a lot of people is it depends. But it depends on what's going on. Like, today, I'm doing an interview with you, and that doesn't happen every day. I think my activities are partly technical still, especially when it's about test automation. A lot with people, that's probably where I spend a lot of my time. And also quite a bit on, call it, marketing and sales, innovation, feasibility, talk to the market.

(Hans at 00:34:51) But I found, by the way, if you look at marketing sales, it's more important to listen than it is to talk. So I do a lot of listening and try to understand and get better solutions. So it's a bit of a mix of that all, and it can vary over time.

(Joel Beasley at 00:35:09) Hans, thank you so much for coming and spending time with me today on the podcast. The value you brought the audience, tremendous. We're going to change some lives. You're like, we won't call you the godfather of testing. You know you're the pioneer, but maybe I'll call you, like, the Tony Robbins of testing because you inspire people to change their ways.

(Hans at 00:35:30) Thank you. Thank you. It was fun to do this, and thanks for talking to me.

(Joel Beasley at 00:35:35) If you ever need anything from me, introductions to anybody that you see on the podcast, if you ever just think, hey, maybe Joel knows this guy or you need anything at all from me, just send me an email, and I'll do whatever I can to help.

(Hans at 00:35:46) Okay. That's cool. So, likewise, if you need anything in the testing world or the automation world or you have a question or you want to talk a little bit more, just let me know.

(Joel Beasley at 00:35:57) 100%. Absolutely. When I come up with the, inevitably, someone's going to ask me, they're going to say, that was amazing. How do we do that? I'm going to say, just go talk to Hans. Right?

(Hans at 00:36:07) That would be cool. Yeah.

(Joel Beasley at 00:36:08) For sure. 100%. I've never met anybody so passionate about testing as me. Jake, my producer, before the show, he's like, you're going to be so excited who we have. We have the best tester in the world. I was like, yes. That's very, very exciting. So thank you so much, and we'll be in touch in the future.

(Hans at 00:36:28) Yeah. Okay. And, Jake, my bribe to you is coming. Thank you very much.

(Joel Beasley at 00:36:36) Alright. Thank you so much, Hans.

(Hans at 00:36:37) Thank you. Bye bye. Bye.