🎙️ Is BDD Dying? Did Low-Code Kill It?

🎙️ Episode Title: Is BDD Dying? Did Low-Code Kill It?

In this episode of Modern Software, host Mike Verinder is joined by Andy Knight (aka The Automation Panda) for a thoughtful, spicy, and at times hilarious conversation about the state of Behavior-Driven Development (BDD) in 2025.

BDD was supposed to revolutionize how teams collaborate—bridging developers, testers, and business folks through shared examples, plain English, and clarity of intent. But somewhere along the way, it became... Gherkin files nobody reads, tools nobody maintains, and a checkbox item that often misses the point.

So we ask the honest question:
 👉 Is BDD actually dying? And if so... did low-code kill it?

🧠 What We Cover in This Episode:

• What BDD was meant to be vs. how it’s used today
• Why Gherkin became more of a burden than a bridge
• The explosion of low-code and codeless tools (like Testim, mabl, and Functionize)
• How AI-generated tests and tools like Copilot are changing the testing landscape
• The rise of “automation for all” and how it bypasses dev-tester collaboration
• Why BDD still can work—and where it shines (especially in complex domains)
• A look at how enterprise systems like Cycle Labs use or abandon BDD
• The danger of skipping the conversation and automating everything
• Whether “Specification by Example” is the future BDD should’ve been

🔍 Quotes from the Episode:

“BDD isn’t just a testing framework—it was supposed to be a conversation.”
 — Andy Knight“It’s not that BDD is bad. It’s just that most teams never actually did BDD.”
— Mike Verinder“We didn’t kill BDD with tools. We killed it by skipping the human part.”
 — Andy Knight

🎧 Who Should Listen to This Episode:

• QA engineers and SDETs wondering if BDD is worth the effort anymore
• Developers who’ve written Gherkin and felt it added nothing
• Test managers or VPs exploring low-code automation platforms
• Product owners curious about how testing is shifting left (and sideways)
• Anyone trying to bring better collaboration to their SDLC

🙋‍♂️ About Our Guest: Andy Knight – The Automation Panda

Andy Knight is a software engineer and quality advocate known for his blog AutomationPanda.com and speaking engagements around the world. He’s a prominent voice in the test automation community and deeply passionate about making software quality accessible, collaborative, and sustainable.

🎙️ Hosted by Mike Verinder

Mike is the founder of Modern Software, an open-source support company and creator of the Modern Software Podcast. He runs the largest Selenium group on LinkedIn and works with companies exploring test strategy, automation tooling, and real-world software delivery problems.

🔗 Connect & Subscribe

👉 Subscribe to Modern Software for more real-world conversations on how software gets built, tested, shipped, and scaled.
 🎧 New episodes every 3–4 weeks featuring voices from dev, test, product, and open source.

Follow us on LinkedIn: Modern Software

BDD, Behavior Driven Development, test automation, low-code testing, software testing, testing podcast, automation strategy, AI in testing, Andy Knight, Automation Panda, Gherkin, Cucumber, Spec by Example, Cycle Labs, Mike Verinder, QA podcast, DevOps, software engineering, developer tools, Agile testing, Selenium, Playwright, Modern Software

Transcript

0:01

This is Mike. Welcome to Selenium Automation User Group. I'm here with Andy today. We're going to talk about Selenium and BDD and what Andy's up to, maybe a little bit of Cycle Labs and everything in that whole world. So how you doing, Andy? I'm doing awesome. How are you, Mike? I'm okay, man. Thanks for asking. So, I did see, I saw your post the other day on, is BDD dying. and I thought that was a really good topic. it was, you know, I remember back, in a number of, QA management led positions that I've had where we were always driving. towards an easier process and a simple process for QA and BDD was always in that discussion. Sometimes we migrated to it. Sometimes we had problems migrating to it. but I thought it was really neat, man. So what have you been up to? And so currently, I am a product manager at a testing company called Cycle Labs, located in my hometown of Raleigh, North Carolina. We build test automation for enterprise systems, most notably warehouse management, but also hopefully branching out into some other areas. This past year, I've had some good speaking engagements already. Back in January, I spoke at Code Mash. It's really cool. I gave a workshop on Playwright. I gave a my favorite talk, Making Great Waves, where I compare QA work to Japanese art. Most recently, I was in the Netherlands of all places, hence the article you mentioned. I gave the closing keynote at Test Automation Days Netherlands, is BDD dying? Oh, we'll get into that soon. But yeah, I've been working on my cars, playing with my dog. That's what's up. have a, was it a VW that you're. 1970 Volkswagen Beetle, which currently is out of commission because I believe I have blown a transmission fork, sadly. But I also have a 1974 Carmanguilla convertible. Yeah. I think it was a karma that, that, that I saw that looked really awesome, man. So I'm a big car buff, right? Not as much, on the VW side, but, but, but yeah, that's, that was a pretty neat looking car, man. And, how's the beetle keeping up? Did you have, have you had a lot of work on it done? I've done the work on it. I've tried to find people to work on it. They don't exist in my area. So yeah, I just in short, I swapped the engine. I did a full interior gut and restoration. know, everything straight down to the metal carpets, upholstery, everything. I put in a very sweet sound system. Gosh, I redid the front or I did break job recently. So yeah, like. That's. Did you buy it with a lot of rust on it and had to replace panels and stuff? body was in really good shape. There really wasn't much rust at all. Well, you're not too, too far up north where you get a lot of salt on the roads, I guess. So I guess that would make. Carolina. Yeah, my Carmagia, opposite story. There's a lot of rust in that one. But I do what I can to mitigate. are you shipping it off to replace panels or just kind of living through it? living through it right now. Okay. Yeah. I saw your post and I saw Marcel's Marcel's got an interesting product to the whoopee.ai and, I haven't, haven't, I haven't got my hands on it. so I haven't had to actually, or haven't had the chance to actually, play with it myself to see how, how well it works. But, But it looked it looks interesting, man. I've seen all his videos on it. I've seen all his talks. it was good to see your reflection on it as well. So, that makes a big difference, man. So, cool. Cool. Yeah. So as it relates to, to BDD, man, why do you think it's dying? Do you think it's dead? I don't think it's dead. think unless there are some major changes, I think it could be dying. And the reason I say that is if we look at the history of where it has come from, where it has gone, with a critical eye, yeah, I feel like the movement has stalled. Yeah. Well, I mean, that's understandable, right? It started out as a process and how do we align product or, and dev and test and through this one cohesive end to end talking language. Um, and then it really became more of, uh, how do we make it a test automation tool? Mm-hmm. that, that has a codeless type of aspect to it. and, and so, yeah, in my opinion, it sort of that process got neglected and the automation tooling aspect took over. and then you started running into You know, other things that like low code automation tools that, that hinged upon the whole basis of what the QA group sort of morphed it into. Right. And like, maybe when you started, you might've had Tricentas, you might've had Tosca out there. That was a low code tool, but it was, you're still spending 12 grand on Tosca. Nobody wanted to pay any of that. Right. But these days you have. low cost automation tools out there, Mabel test them, functionize. I'm not going to name the other ones, but, but, but, you have those low cost automation tools out there that, that, you know, you can get into affordably. All right. And not have to pay $12,000 a license or anything like that for, so, I could see how it morphed and sort of how it's, how it's gone going on the trajectory. I guess you could say. that it is. But I don't know what are your thoughts on that? Yeah, I mean, I strongly believe that the principles behind BDD are absolutely valid still today because they address more of the human problems, not so much the tech problems. How do we collaborate? How do we communicate? How do we produce artifacts of our development process that can help us move forward in building behaviors of high quality and high value? Though that more than ever is, is important to this day that hasn't changed. But where, like you said, where BDD tooling initially went, it went very quickly into test automation, which might seem like kind of strange at first, but we have to remember where it came from. BDD came out of the shortcomings and limitations of test driven development, TDD, which then came, going back further into history, came out of the whole 1990s object oriented hangover, extreme programming, to have what eventually became agile, all those kinds of things. Where in the 90s, of software engineering development was focused on things like design patterns, things like how can we do everything we can in code? Hence you had unit testing frameworks come out, right? You have the Gang of Four design patterns, you have S unit, J unit, N unit, all these units. into the thousands then there was kind of BDD was kind of this wake up moment of, shoot. It's not all about code. What really matters is the business value. The features we're trying to build the behaviors. So if we focus on the behaviors and our development and we drive towards that because acronyms are catchy then. And so that's with, with that kind of mindset, think naturally the first tooling was for test automation frameworks to say, we can write our specs in this business oriented language and we'll call it Gherkin because I don't know, vegetables are cool, right? So you can write that and it's plain language, everybody understands it. Then we can take that spec and automate it into LivingDoc. And that was like, that's cool. It was a natural progression from the history and it was an easy enough thing to build in tooling. Like you said, the tooling went very much in the automation direction, but not in the collaboration direction. And I maintain that to this day, nobody has really built meaningful tooling for the collaboration side, for the collaboration practices. Yeah, because people have had these one-off things here and there. Like I've seen example mapping boards. There was that whole Cucumber Studio thing, which I mean that They didn't really nail it, I don't think. It was just kind of like glorified feature files. And it's like, I don't need a special web form. I need tools to actually help me carry through the process. And like you said, there's nothing to carry you from inspiration to implementation, right? There was nothing carrying me through. is the discovery phase. This is the formulation phase. This is the automation phase. All we had was automation phase. It was like, you know, and, to be clear, there's still a lot of automation and people using it like that. I'm not trying to, uh, paint a picture that it's, it really has died. If you look at an enterprise space, there's a lot of enterprises looking at it. Every time I pull the Selenium group, at least 25 to 30 % say that they're doing a BDD implementation. Holy cow. Yeah. Like. the things that you can do. That's what you're doing. even There will be cucumber tests running after all of us are long retired. Now, even when I was at Catalan and I surveyed the same group at Catalan, different product, right? Same percentages applied. It actually was a little higher even with Catalan. So there's still a lot of people using it. It's still really active and, in very profile high profile in the, in the enterprise space, mostly in the enterprise space. So and straight up, like I have no problem with using a BDD test framework. I love it. I think it has some very distinct advantages that regular traditional test automation frameworks don't have. Even if you're not doing the other BDD practices, I think it's still valuable to use a BDD test framework in many cases. And I think the reason why, like you said, about a quarter of all people are, are entrenched in this because a lot of testers and automation ears. saw that value in it. They're like, oh, can think before I code. I can have this extra layer that handles my test case and have the test code separate from that, but connected that I can reuse my steps that ultimately I can have this domain specific language for testing. I Gherkin has become lingua franca for testing. Like you look at even in 2025, like all these AI driven tools that help you formulate and all this stuff, all of them, you... When they say like you have plain language steps, they all write them in Gherkin, all of them. So it's like even divorced from your traditional BDD framework, Gherkin lives on. And that's probably one of the greatest contributions to testing that we have because given when then framing it follows a range act to certain pattern is brilliant. It's simple. It's awesome. Right. but go ahead. Sorry. think the biggest, so sounds like one of the biggest obstacles has been sort of transforming the business to be able to use that. I would think so. Because with the pigeonholing or with the primary tooling being test automation, BDD got pigeonholed as a tester's thing. Right. When it was supposed to be cross-role collaboration, biz dev test, and whoever else all together, the plain language was for anybody to be able to read and understand and have living documentation. It was meant to foster collaborative practice, but unfortunately, a lot of times that just didn't happen. Right. And my... My hypothesis on that is that it was because there was a lack of good collaborative tooling that was integrated, right? Because the collaborative stuff was left up to practice. If you look at people process product, right? We had product for automation. We were relying on people and process for the collaboration. And it's like, well, it wasn't sticky. Cucumber will keep running after we're all long and gone, but who's going to be doing example mapping? I don't know why there's nothing to. to help people through that. And so if that tooling were co-equal and were pulled off right, then I think BDD would have had a different impression upon people. I think it would be much more widely adopted almost to the point of agile even potentially, but it just never manifested that way. And it was always this... I don't wanna say niche thing, but it was this side thing, extra thing that people either absolutely loved or absolutely hated. Does this year play for VC funding, Andy? my goodness. Well, I mean, if, if I can say at cycle labs, we very much still believe in a behavior driven mindset, right. that, that it, it's not so much about following these precise rules, but rather being minded towards putting behaviors first, seeing these collaborative and automated practices following the, the, the path from inspiration to. implementation of discovery formulation automation. And we are actively productizing these things to provide better tooling for helping you and your team do better testing and ensure higher quality. So like we believe in these ideas and we are thinking like, you know, where have the weaknesses been in this movement and how can we help do this better so that BDD is not dying, but rather we can say much like we say we do agile, we do DevOps, hey, we do behavior. Yep. And so cycle labs is just for supply chain. What is, what is that again, Andy? sure. So what is supply chain or what is CycleLabs? Sure, sure. So CycleLabs, we are a test automation company. I shouldn't say test automation company. We are an enterprise software testing company. What we provide is a platform for enterprise level testing. When I say enterprise, what I mean is where there are these large systems that people are Not building entirely themselves, but rather plugging into and configuring and building their workflows in that. So a good example that most people think will be like Salesforce, right? Salesforce is an enterprise platform for CRM. And so what you do is when your company has Salesforce, you go in there and set up your whole CRM in Salesforce. so there's like Salesforce for CRM, there's SAP for ERP, you've got Workday, you've got Oracle. So we focus primarily on the supply chain space. So warehouse management systems, a couple of these examples, Blue Yonder, Manhattan, Kerber, these kinds of things. And so these are big enterprise systems. They have web components, have API components, they have terminals. Some of the systems are very new, some of the systems are very, very, very old. And the challenge with Supply chain testing is not, I have this little web app. How do I make sure I have a good testing strategy for functional performance? But rather, hey, I've got a warehouse in Raleigh, North Carolina. I got another one in Chattanooga, Tennessee. I've got another one in Alpharetta, Georgia. They're mostly similar, but of course there's special snowflake configurations for each. And I need to make sure that this palette of candy bars doesn't melt on the way of the palette with the scanning of the license plates that ends up in these particular spots in the warehouse and I can ship it out on trucks. I can receive and ship and all this kind of stuff. Right. So you have, like I said, you have people at desks working web apps, you've got API's flying, you've got people in the, these actual warehouses running together with robots and hand scanners and, even now mobile apps on their iPhone scanning and making sure that all the candy bars are, are cycling around on the pallets and the, the, the, the, the pushers and stuff. Right. That's the challenge. So it really is an end to end enterprise system. How do you test that? And so the cycle testing platform is geared towards that. Yep. That sounds, it sounds like a fun platform to be testing is you got scanners, so hardware involved, right? I remember I was at a dairy.com and dairy.com was supply chain for the milk industry, obviously. Right. And so it was from farm to grocery store basically. Right. But they go pick it up at the farm, put it in the truck. How's it look at the truck? Right. coming into the plant, they have to test, test it. You know, you have to keep it cold the whole time. Right. I have to monitor it really well. and how you distribute it out to the grocery stores or, or package it basically. Right. So, so yeah. And your WMS is even much more complicated because it's much more productized, I guess you could say, but, but, these enterprise platforms, idea is, whatever you're shipping, candy bars, video games, milk and dairy, you can customize the system however you need. the complexity comes in that because it's like, okay, you're not testing to make sure when you click this button, something fires. You're testing to make sure that your processes in these systems for how you manage all this inventory are working correctly. Bam. Maybe you should test that. do you see, guess you're in your implementations. see BDD used often in these shops or not, or is it still around 20 to 30 % or is it in most of the customers and partners we work with, not all, but many of them historically speaking, they don't even identify as software people. They don't identify themselves as a developer or a tester. They see themselves as very much in their business, right? If they're pushing candy bars, they're in the candy bar business. If they're pushing milk, they're in the dairy business and they happen to have inventory that they need to keep. in warehouses and oh shit, we need to make sure that all those systems are protected so they don't melt or spoil or go somewhere they shouldn't. And so like they're, they're not even a point. If you're asked them like, do you do a BDD process or not? They'd be like, what are you talking about? You know, um, some, some customers to be fair are more advanced. They, they actually have teams of like SSTATs who would go in and use cycle to, build their automated tests at a higher scale. So we get a full spread, but I would say like, it's not that the customers and partners that we're working with do BDD already. It's not that they're asking to do BDD. Rather, they're coming to Cycle Labs and saying, we need help. We need help with making sure our systems work, with testing this and to have the protection of fast feedback and the continuous testing to make sure when we make changes to our system, that it's all good. And we're going to them and saying, great, we're here to help. We're happy to help. Here's our testing platform and here are the principles that we have put into it. Yeah, this is your recommendation, right? Your philosophy of your methods that you use, right? and I wouldn't even say that that cycle labs is like pure BDD stuff. We tend to describe ourselves as behavior oriented or behavior minded, right? We're not trying to advocate that you must go through example mapping and you must write the most perfect gherkin and all. That's not what we're about, but rather we're saying we're inspired by these principles and we are baking these opinions into how we build our testing platform. Because ultimately, whether you use these fancy words and these acronyms and call it this, whether or not you do that, you still got to do all these kinds of things that the process outlines for you. Right. And so that's, that's kind of how we are approaching it. So it's like, I'm not going to go say cycles of BDD2, but what I will say is that it is very much favorable towards a behavior driven mindset. Do you think Gherkin itself is a reason why people have kind of gotten hung up on BDD? I think so. I think... Like it's kind of confusing. It's kind of, it's not real English, you know? So I could see a product manager saying, look, I just want to write this requirement on what it does or something. Right. yeah. I think there are two hangups people have had with Gerken. One is the challenges with using it as a semi-English language. People get hung up on, need to write it perfectly. And even I was that way for a long while earlier in my career. But yeah, people will be like, I have to have perfect syntax. I've got to write these steps right. And at this point, I'm kind of like, look, when you're, when you're in a collaboration session, you know, before you are trying to automate this, even just talking it out, don't worry about your punctuation. Don't worry about syntactically perfect. What you need is you need scenario and given when then if you can get that, anything else goes, you can wordsmith it later. And, and so to, get people over that hump, to realize given when that is meant to structure it as a range act to cert given I set up my system. when I take an action, then I verify an outcome, given when that's the golden formula. Get that? You're good. Right? Because what we find, if you don't have those guardrails, is that people will test more than one behavior at a time. And that's when things get complicated and bad and icky and confusing and the vectors fly. And it's like, we're trying to avoid that problem. Hence, given when that. Keeping it simple like that, I think is easy to understand, Gherkinizing everything is people just start to distance. I've seen people start, especially non-technical people start to sort of distance, you know? I think that's a shame because I find Gherkin to be very helpful for keeping people focused because you need a little bit of structure to your language because I mean, the opposite is completely free form where all of sudden your acceptance criteria is like 72 bullet points and you're like, what? You know. you would know as well, if you're going in front of all your, all of your clients and you're, you're saying, our playbook is BDD or the one we would recommend. And you're the folks that you're talking to are non-technical. They're either very accepting of it, right? Or you get that friction, which turns them off, but it sounds like they've been very accepting of it so far. So indeed. And I would even say to the friction you mentioned with Gerkin, if you frame it reasonably well given when then, and you do that for all the behaviors and examples you're trying to map out, what you reveal in your design time and your planning time is the total cost of ownership of a feature. Right? mean, people sometimes they think something that they're going to build is simple and straightforward. And they're like, well, yeah, because they have that preconception in their mind is like, of course it's going to be fast. It's going to be easy. But when you start to unpack and you start to, to define these things and spec them out, um, using Gherkin as a tool like that, you start to find, geez, as you uncover these edge cases, as you have conversations and discover things that you didn't think about before. Um, and as you start to write additional scenarios and additional steps, you start to see, oh, there's a lot more here. than I first thought maybe. And so some people don't like that friction in the process, but I think that is important because that's immediate feedback to say, hey, this is what it's going to cost to build this thing right. And it's out there. You have the artifact, you have the evidence, you have the plan, you have the size. I mean, gosh, I've railed on this. for another tangent here, but like. We spend like in traditional agile scrum, you spend so much time and planning poker, guessing the size of a thing. Just do BDD example mapping, write out all of your gherkin scenarios and boom. What if the sizing is actually the number of scenarios you have for a feature done, because instead of guessing, you're actually planning. Yeah. The whole agile is a whole nother and sprints. mean, that's a whole nother cluster of a discussion. Right. And then, and then management coming on to me, it was never agile was never meant to be this reamed out thing. was, it was just like everything meant to just be a collaborative session on, getting work done. And then it became over management eyes and, and how it became a productivity tool more than anything else. Right. You're not being productive enough, right. And measuring productivity. So it's been a, yeah, that's a whole different. it hurts so bad, but it's so true. But yeah, you know, right, man. So. What's, what's Andy up to this year? I saw that you're doing a conference in Texas again. I saw that. I saw that post today. indeed. So in terms of where to find Pandy night in the world, I'll be in Austin, Texas in, in mid April for PI, Texas, which is my, well, it's probably now my favorite Python conference in the world. I absolutely treasure my time in PI, Texas. I've got some very good friends there. One of my best friends in tech, Mason Egger, awesome dude. He runs the conference. He's PI, Texas president. and so it's. Part of it is like, I get to go spend time with him and some of my other friends. But also it's just a very well-run regional conference. It's two days on a weekend plus an extra day on Friday for tutorials. Good size group. I think last year attendance was like 250 or something. So it's big enough to feel like you're part of something, but small enough that you can actually have good one-on-one conversations, meet new people. it's... small enough that it's not like over commercialized, right? community driven, you know, like I don't even remember. think they only had like one or two sponsors last year or something. Maybe I could be wrong. I might not be remembering right. But it's, primarily for the community, by the community, as many Python events are. And I mean, I, cut my teeth speaking on the Python circuit. That's, that's the origins of my speaking days. I, I love it. I mean, I, I don't do as much with Python these days. I don't. go to as many of the Python events as I used to these days. But I mean, every year on the calendar, I make sure if there's one Python event I go to is PyTexas, hands down. And so for anybody out there who likes Python, who likes like creative programming stuff, learning new things, meeting awesome people, come to PyTexas, it's worth it. No, that's a great conference and, I'm, I may even go it's in Austin. It's not that far. It's at the central library, downtown Austin. I try to find a hotel with a walking distance. So it's just, I'm in that downtown Austin bubble the whole time. Give me some Whataburger. and a neat place to hang out anyway. Right after, plus Rogan. don't know if you've ever been to Rogan's comedy club and his comedy clubs and downtown Austin too. That's kind of neat too. But, yeah, I would, I would encourage people to check that out. it's, know, it's, it's ironic. I didn't get to, I didn't get to go to the selenium conference this year, which is tomorrow. It'll be by the time this comes out, it'll be done. But, and I guess obviously you didn't get to go either. Nah, I've got to be very picky with my travel these days because I'm not in DevRel anymore. I don't have this expense account and this expectation to go speak at all the places in the world. You're not doing 40 conferences a year anymore, Andy. goodness, no, it was too much. mean, for 2023, I had 65 speaking engagements. It's too much. And so I am much pickier about what I choose now. And so like there are... on the speaking engagement though. Like this could be a speaking engagement, right? So, but like traveling somewhere and you know, getting in, getting in front of a thousand, 1500, 5,000 people. Like that's a, that's a different prep altogether. Right. So, I mean, that's a, go ahead. I will be going to start East again. I'm giving all my workshops, my B2D workshops, my Playwright workshop. And this time I'll be giving a PyTest workshop. In mid-May, will be speaking at DevOps Days Baltimore, which I'm originally from Baltimore, born and raised. And so my hometown does a DevOps Days thing. Heck yeah, I'm going to be there. So that's exciting. I was going to be at DevOps Days Raleigh, but unfortunately they had to cancel that event because they could not get sponsors. That one hurt because it's like, no. you been to those before? yes, DevOps Days Raleigh is awesome because we have so much tech and software here. It's actually a pretty big event. No, we, we get, I mean, I was at the one in Dallas. Uh, I don't know, probably four or five months ago, we, we get a pretty good crowd for, uh, the one in Dallas. So really love how the DevOps Days events structure their conferences. They have a good mix of the short talks, the long talks, the workshops, as well as their open spaces. I like the short talks too, right? I don't like the big, you know, just the big, I mean, the, big conversations are nice. It's okay to have like a keynote or something like that. It's okay. But I like the short talks of, this is what we're doing. and, and just quick, you know, and then, okay, move off to the next one. I think that encourages more people to share their stories. and it's not as, I don't, I don't know the right word to say for it. It's not as, I don't know. It just brings the bar up in the conversations and it, and it lowers the hesitancy of people to get involved. So, yeah, I really like it when they do that. And I think they did, they did that at the last DevOps and Dallas too. So I don't know. I really liked that conference. That's really, that's really cool. It's good to hear you're going to at least two of them. So. normal. how many of those do they have? ton. Any mid to large size city probably has a DevOps Days event. format-wise, they all swap notes, so they're all very similar. Yep, I've been to the one in Raleigh before. I've been to the one in Baltimore before. I'm going to the one in Baltimore this year. Yeah. And the other thing is that, you know, if you go to the test conferences, you know, you see the same, it's the same people over and over and over and over again. And, and you really see, you do see some test people in the DevOps. Uh, but mostly it's a, it's a whole new set of, it's a whole new crowd. Right. So, and a whole new set of tools. Right. So, uh, about testing is that those skills are very transferable to other areas. And so it's very easy for us as quote unquote testers to go crash a developer conference, a DevOps conference, pick your programming stack conference. Very easy for us to enter those areas. Mark? Well, anything else you want to talk about, Andy? man, I mean I could go all day, but it's alright. We'll just have to have another episode. right. Well, thanks for hanging out with this man and I look forward to seeing what your next updates are. All right, brother. Take care.