The Future of DevOps: AI-Driven Testing with Fitz Nowlan and Todd McNeal

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe and welcome to another episode of the Test Guild DevOps Toolchain podcast. Today we'll be talking with Fitz and Todd all about gen AI trends with testing and DevOps. Really excited to have him on the show. If you don't know, Fitz is a software engineer and founder. He earned his Ph.D. from Yale University in Computer Science with a focus on network and distributed systems, so he knows his stuff. He's worked at big tech companies like Google and Microsoft and startups, and co founded Reflect, which was acquired by SmartBear in 2024. You may have heard of Reflect. They actually Todd, who is one of the other co founders, has been on the automation podcast in the past. He did some webinars, got really great feedback on this tool. So really excited to have Todd join us again. Once again, he is a co founder of Reflect, a test automation tool that can execute minimal test cases using AI. Really cool stuff. And it was so cool that SmartBear acquired them in 2024 I think at the beginning of the year. And Todd is really passionate about making test automation easy to create and maintain. I really think you're going to enjoy this and how automation and testing works into the DevOps toolchain. You don't want to miss it. Check it out.

Hey, if your app is slow, it could be worse than an error. It could be frustrating. And one thing I've Learned over my 25 years in industry is that frustrated users don't last long. But since slow performance isn't sudden, it's hard for standard error monitoring tools to catch. That's why I think you should check out bugsnag, an all in one observability solution that has a way to automatically watch for these issues. Real user monitoring. It detects and reports real user performance data in real time so you can quickly identify lags. Plus you can get the context of where the lags are and how to fix them. Don't rely on frustrated user feedback. Find out for yourself. Go to Bugsnag.com and try for free. No credit card required. Check. Check it out. Let me know what you think.

Hey Fritz and Todd, welcome to the Guild.

Hey, thanks so much for having us. Glad to be here.

Thanks for having us.

Great to have you back, Todd. Good to see you, Fitz. So before we get into it, is anything I missed in your bio that you want the Guild to know more about?

Nothing on my end. No, that. I think that sums it up.

Yeah. I don't think so. Yeah.

Awesome. I may have asked Todd this. So I always ask founders, like, what got you into this particular space? Why? Reflect.

Yeah.

So Todd and I. One part, I guess, that was relevant for the bio is we worked together for five years at a previous company, and we were both directors of engineering there, managing teams. And we were just constantly doing this manual regression pass. Every time we would push out new code to our. We had a B2B SaaS offering at Curelate was the name of the previous company. So we would push out new code and we would run through these manual regression tests. And it just felt like we should be able to record those workflows and run them back on demand. And that was really the crux of it. So we set out to build that.

Love it. So obviously, it's obviously successful companies. You were acquired, they saw the awesomeness that what you created actually adds a lot of value. So I guess my question is nowadays, when I started software testing looked a lot different. With AI, there's been a lot of hype. Just curious to get your thoughts on if I'm a beginner in testing, what does the, you know, the next two years look like compared to where I may have started? How much should I really know about AI? What is the hype and what is real big question. But maybe one of you can. Both of you can handle it, but whoever wants to take it first?

Yeah, that's Todd expert Todd's expertise. He'll walk you through the life cycle.

So I think, you know, in technology, things are constantly changing. That's the constant is change. So I think nowadays, if I were a tester, I think it's really a mix of keeping up with the latest technologies, you know, AI being kind of the big one, and then also getting back to basics and, you know, really focusing on the value that testers provide, which is delivering quality software. Right. So I think that's the thing that's not going to change is the more that you as a tester can deliver that value for your company and for your users, the more valuable you're going to be to the company. And it's just the methods of doing that are evolving now.

All right, next question that comes to mind is a lot of companies are DevOps first companies, and a lot of the responsibility falls on developers to do pretty much everything. Is that something you've been seeing and how much of them actually care about AI, about automation and how does AI maybe assist them with their day to day activities?

I would say definitely agree with you that there's a huge trend toward developers owning DevOps and maintaining their own infrastructure. Even in terms of the AI influence, I think it's still very early innings and I think what you saw from a lot of companies in the last year was a chatbot, basically some, you know, chat with your infrastructure or chat with your account settings or configuration and those were things that you could have just found on the settings page or you know, just by loading the web app. Where we tried to differentiate and where I think in the future the real killer apps will appear is when AI performs functions on behalf of the user. And so when the AI doesn't just tell you something, but it does something. And that's really, that was the core of our AI integration in the last year and I think that's what is delivering value for our customers. And I think that's where again the killer apps, the really the differentiated AI based companies will be found in the next couple of years.

So I don't know if you rebranded. Is it still called Reflect?

Yeah.

Yep.

All right, so for the folks that may have missed it, like I said, I'll have some links to the webinar that Todd did back like last year. What is Reflect like when we're talking about AI and automation? Like what does Reflect? How does Reflect see AI? What automation? What's your special sauce say?

Yeah, so Reflect is a web automation tool and there's many tools for web automation like code based tools like Selenium and Playwright and low code. No code tools where that would be one of the, that would be a category that Reflect is in. I think what's differentiated with Reflect is that we starting, you know, middle of last year, we really went all in on generative AI and using that both for self healing, but also the ability to describe the test in English language. So one thing that we observed, you know, being in the industry and having this in market for a couple years is that a lot of times when you're automating something, especially as something like record and play, it can be too specific. And what that causes is false failures, basically flaky tests where the thing that's recorded when you click on a button is a selector or maybe a couple different selectors, but it's super duper specific and any change that button could cause it to Fail. Whereas something that's represents more the intent of the action, like click on the login button, like literally that sentence is actually more correct, because then as long as the AI can interpret that, it can take that sentence, click on the login button, and perform that action as a human would. So if there's a button that says login, it will click on that wherever it is. But if there's a button that says register and no other buttons, then it should fail the test like a human would. Yeah.

Another really good example there along those lines, Joe, is if you imagine we're no code, but with reflect AI, we're now actually no manual too, because you used to have to perform the action to get the record and play tools to work, but now you can just describe what you want done with precise intent, and our AI can interpret that and then perform the action on your behalf. So a really classic example here is if you were to manually click on Jane Doe, the second entry in a table, the recordant play doesn't know did you mean to click on the second entry in the table or Jane Doe wherever that entry appears. Whereas if your intent was click on Jane Doe, then the AI can interpret that and can find Jane Doe. Similarly, you could express an intent of click on the second row, and the AI would always click on the second row. So that's where intent is actually more precise and simultaneously more robust and resilient to application changes.

Absolutely. And along those lines, Todd, when we first talked you, this was before multi, I think you called it multimodal AI came out where it uses both audio and video to help with automation. And I guess Fitz touched on this, where automation can now do things well, maybe just bubbling up insights, but actually act on your behalf. Is multimodal AI a thing now? Did you bake that in since we last talked? And how does that solve maybe other challenges we may have seen with automation in the past?

Yeah. So that's something that we've incorporated into the model, and it's sort of like the. Just the beginnings of it, but it's something that we're really. We're working on now, adding it in kind of full force. If the reason that multimodal is so interesting, especially in a testing context, is that if we think of a human tester, the interface that the human tester has for testing a web application, or really any sort of application, like a mobile app or desktop app, is your eyes and your keyboard and your mouse. That's a universal interface. And so the vision AI kind of is the Final piece of the puzzle for having automation interact in that universal interface. Keyboard and mouse is pretty easy to automate, but to actually view and interpret what's presented to you on the screen up until now has been a very difficult and, you know, state of the art really couldn't solve that. But with multimodal, the promise is that it can. And so that really anything that has that universal interface, a screen and input devices should be able to be automated with this approach.

So do you see this as replacing testers? Like, what's the role of AI that you see in this space? For someone that's interested in software testing and developing, is it a replacement? Is in a. Is it something that, that's an add on that helps? It's almost like a sidekick. How do you see it?

I see it as an augmentation. So the best AI tools in my opinion are ones that fit into your existing workflow. Like Copilot for developers helps, you know, replace, you know, basically having to look stuff up on Stack Overflow or, you know, the Java Docs or something like that. And it makes you build things faster with the same level of quality. But it's still human in the loop with testing, we think that's the same thing. You still need humans to make judgments on. Is this correct or not correct? You know, describing what functional requirements are, you need human experts. You know, maybe there are business analysts or people participating in UAT that have subject matter expertise in, you know, medical billing codes or things that may be more esoteric that an AI would have very, a lot of difficulty really describing or knowing whether it's correct or not. But it's, it's an accelerator, so it allows you to get more done. And I think that's what testing teams have always struggled with is there's, you know, you'll never meet a testing team that says we have too much testing, like we're testing too much. You know, it's always, it's never enough. There's never enough time, it always takes too long, it's not working correctly. Those are things that are really ripe for an AI kind of augmentation.

And I'll just add one distinction there to make. I think along the lines of what Todd is saying is that if you think of a tester today as both as the person who is in charge of knowing what to test as well as performing executing that test, then we think that there's still very much, absolutely a role for someone to know what needs to be tested and to know the requirements of the application where we see AI providing a major augmentation, potentially a replacement, but more so an augmentation is on the execution side of things. I think you'll still want that expert in the loop to validate that the AI is in fact taking the correct action in certain edge cases or esoteric things, like Todd was saying. But we see the execution as basically being something that the AI can more or less take over. But you still need an expert. You still need to know what's worth testing and what the requirements of your application are.

Absolutely. So I love how you said it's augmentation and accelerant. I know with DevOps a lot of times teams tend to stop failing or start doing more automations because the automation they created are the scripts that aren't really accurate or they're really bulky, or they take a long time to run and to create. So how does this help that story? Maybe how does it help accelerate DevOps and delivering to the user when you have maybe AI helping with this?

So I think it's similar to what, you know, the previous generation of DevOps tools did, which is, I remember when I started my career in the mid 2000s, it was waterfall and you needed a dedicated infrastructure manager and dedicated ops teams. And, you know, there was a wall between developers and the ops team. And by kind of breaking that down, things moved faster. But it ended up being a flywheel where because we can deploy faster, we can ship faster, and now we're shipping faster, so we need to review it faster and we need to test it faster. So it's not that you kind of rest in your laurels. So I think where this fits in is because we have those previous accelerants where we can deploy things in 15 minutes and have it in a new environment that spun up, that has good test data. Now we need to fix the kind of lagging part, which is, you know, how do we test everything we want to? A lot of teams right now, the way they handle that is, well, we need our test to finish in 10 to 15 minutes if we're doing it on every pull request. So, like, we need just basically smoke tests. But what if you didn't need that? Like, what if you could actually have comprehensive tests? I think, you know, if we can deliver a testing approach which lets you get high coverage with high confidence and actually be fast, that's where you can actually, you know, add that to the DevOps process that already is, you know, much improved over the previous way of doing things.

Absolutely. And I guess another thing I've Seen with a lot of the open source tooling and everything is back in the day, it was easier to track how tests fit to requirements and, you know, changes in those requirements and such. So I think one good thing about working for a vendor like SmartBear or getting acquired by SmartBear is they have these other solutions as well. Like I think they have a test management system called Zephyr. So is there any now integration with AI with Reflect and Zephyr so that it can then know what the requirements are and then do the automation for you without you having a guest or kind of do the tying in this requirement ties to this test?

Yeah, so one of the exciting things that we're releasing as part of SmartBear is an integration with Zephyr, specifically Zephyr Scale, which runs within JIRA and is very popular test case management tool in Jira. And with our approach to Genai, where you can take an English language sentence and execute it within the web browser, you could think of a test case, a manual test case, as just a set of sentences, which are a set of instructions for the test automation. And so what our integration is going to do is it allow all Zephyr customers to take their existing manual test cases and run them directly as automated SAS using this AI approach. And so we're actually launching that later this month and it'll be freely available in beta for all Zephyr Scale customers.

All right, so that sounds pretty crazy. So can you walk me through what that looks like? I have a bunch of tests in Jira. I have a Zephyr Scale. Why push a button? And they're automated. How's that going to look? What's the visual for people that are listening in?

Yeah, it'll be pretty cool. So if you think about it, you've had this repository of tests that are rich and valuable on their own, but to get that value, you always would have to have a manual tester come in and perform those actions live in the browser, and then mark, you know, the progress, pass, fail, stuff like that. Reflect AI takes as input, as Todd said, sentences. And all of your test steps in those test definitions are sentences. So yeah, more or less you're going to get a button that says run automated test next to your test scripts in Zephyr Scale. And when you click that, we'll pass it through Reflect and we'll use AI to augment and improve those sentences where we can. And so hopefully from the output of that, we'll will be a well formed, well described test script. And then we can go and execute each of those well formed test script steps using our AI and then return the results back. So maybe a little bit of handholding or guiding or narrowing of your language in those test scripts as you start to use Reflect AI from Zephyr Scale. But the hope is that over time, you'll get better at describing your test steps in a way that Reflect AI can execute them automatically. And for the bulk of your tests that are well described already, Reflect AI should work on its own. And it's a seamless integration. When you're in your Zephyr Scale account, you automatically have a Reflect account, and the results are posted back to your Zephyr Scale account. So it's kind of like bringing an execution engine to your Zephyr Scale account.

All right, I know you're not salespeople, so if I had a Zephyr Scale account, you're saying I get Reflect out.

Of the box for the beta period. Yeah, everyone in Zephyr Scale will get it for free, out of the box. And over time, we will look to work in the correct pricing. They haven't sort of finalized or published that yet, but there will be a beta period where everyone who's a Zephyr Scale customer will get access to Reflect AI for free.

All right, so can we talk about some of the impacts of this? Because I think it's kind of crazy. So now I think a lot of things is you have a requirement system, you have your requirements, and then you have your code base of your test. Someone makes a change to the requirement, you're like, oh, dang. All right, test this, test that, test that test. Need to update these tests. Is this going to be a requirement where these. Rather than having to worry about that, it just, you go to Jira, you make your change, or your Zephyr Scale, you press the button and it just creates the new test. Or do you. Or does it update existing tests? I don't know if that makes sense, but just trying to see how it streamlines the process.

No, it definitely makes sense. So what Fitz was describing is when you're first adding tests for the first time into Zephyr, it's sort of a process where we're guiding you through. Hey, we've made these improvements. Do they look good? Hey, we're going to ask you to watch the test run as we run it. If there's things missing from the test, like you didn't describe the username or password or something, you have to enter it, but it walks you through that process. Once you have your test cases automated. Yes, over time they're definitely going to change as your requirements change. But you, that process is basically the same as what you do today. You go into Zephyr Scale and change your requirements, which is in jira. When you run it the next time, those updates are going to be passed to reflect. So it's, there's no kind of remembering to do it over here and then doing over there. It's all seamlessly connected.

It's a bi directional sync, you could imagine. And then as soon as your requirements change, as soon as you update that test, we'll start, you know, we'll be able to execute it.

This may be on your roadmap. You probably already thought about it. So when we talk about requirements, there could be a security requirement, it could be an accessibility requirement, it could be a performance requirement. These are all tools I think that SmartBear has. So is this just for functional requirements? Will it eventually go to like performance requirement like thou shall, the login page should load up within 10 seconds or stuff like that? Or is that just like not happening? Is it on the, is it possible? Is it on the roadmap? How's that going to work?

We're definitely focused on the functional requirements to start, but I think it's ideally, anything that could be automated will be automated through this approach. And you know, there's some things that I think still make sense to do in code. Like for example, if you're writing API tests, it's a little, it's a little awkward to write that as English language sentences. Right. So we don't want to try to fit a square peg in a round hole. But if it's common for folks to document requirements or test cases in English today, I think that's certainly ripe for us to try to automate through this approach.

Yeah, and I think there is an opportunity in the future because requirements are often expressed in plain text format. That suggests that the AI should be able to digest that, make heads or tails of that, and then turn that into sort of some sort of structured form and derive value from that. I think Todd's example of the API testing is a really great example because there are some things that even today aren't quite expressed in plain text. They are always expressed in some sort of structured programmatic form. And so those things aren't perfect fits for the LLM the way the generative AI, the way that. But you know, anything in plain text is.

So how specific must the requirements be? I mean, yes, it's used in Plain English. But you could still have a very, not very clear requirement that someone writes like, how does the AI, the execution engine handle that? Then is it smart enough to know it or does it bubble it up? Hey, you need to give me more insight.

How does that work?

It's a little bit like the latter there. So when we come across things we can't do, we will ask you for input, but we will have a go at trying to do it ourselves before we sort of throw our hands up and go back to the user. So the idea here is the straightforward instructions we can do today. If there's something that's not so straightforward, we will attempt to tease it out and we'll try to explain what process we took to tease out that action or that, you know, that instruction. And then when we can't or we think we've gotten into ambiguous territory, we'll go back to you. In the future. There is a sort of a second level of AI processing on the roadmap that we have, which would allow us to hopefully more automatically resolve that hyper, that extremely ambiguous requirement. And Todd, you probably, maybe you want to add a little bit there as well.

Well, I would just say the way I like to describe it is to have the way the specificity of the test that you're writing, the way to think about it is written. Write a test for a manual tester that is a new employee on your team. So if you could write a test and give it to that person, or maybe give it to three new employees and they all perform the same actions, come come up with the same result, then our AI should be able to execute it too. So practical example, but you can't say like go place an order in an E commerce because you know what, you know each tester is going to try different products. They're not going to know, you know what to do if the product's out of stock, should I fail the test. But if you get to the level of specificity where they all did the same thing, then you're good. That's the ideal.

How does this fit into a DevOps pipeline in CICD? Is it who handles the execution of what to execute other tags where. All right, here's someone checked in code run this suite of tests. Does it run all the tests? Is that that type of communication is someone noxious have to go to Zephyr Scale and say run these tests.

So it actually it's. It gets at a workflow today that is a little cut off from the DevOps workflow, which was if you look at a. A typical customer that's doing manual testing, a lot of what they're going, a lot of them, what it will look like is you have DevOps workflow up to the point that you deploy to, say, QA or staging, and then you go to the testing team and say, okay, good to go. And it's in their hands until they hand off and say it's good. But that process today is literally, you know, going in, clicking buttons to say pass or failed, opening up bug tickets. It's cut off from kind of this automated pipeline, but this approach actually gets it more integrated in because to start off with using this reflect integration, yeah, you would still go through into Zephyr Scale. You would click the individual tests to run it. Once you've gotten enough tests where you can do it in a regression cycle, there's a button there to click it to say, run it for all the tests. And then as you get more sophisticated, you can start using some of the automated capabilities and reflect to run it automatically after a CI pipeline. So you could actually kind of think of this as a way to go from, you know, a process that's maybe totally cut off from your DevOps pipeline and start slowly integrating it into it.

So I'm just trying to think now of this integration. Say someone has Zephyrus Scale. They're all jazzed up now after hearing this. How would they get started? Do they need to rewrite anything? Or is it like you said, they just. You're good to go. Press the button. Like, how can someone take advantage of this? Or maybe try the beta version with the lowest amount of overhead on their head, on their plates to do it?

Okay. Yeah. So it's going to be open to all Zephyr Scale customers. And so when we launch it later this month, there'll be a run automated test button next to each test within Zephyr Scale. And as Fitz described, when you run that, click the run button. It's basically going to walk you through the process of getting that into an automated vault state. So the first step is going to be, you know, looking at the test and reflect AI saying, okay, here are some improvements we made. Like, there are some spelling mistakes over here. There's some grammatical mistakes over here. This test step actually is a couple test steps. So we split it out. You can review it, but the AI does that all for you. You just review it and say, okay. And then the next phase is, okay, now we're going to start to run it. Let's watch it. If we Run into any issues like where maybe you didn't specify, you know, this particular action. So we don't know what to do. We're going to ask you to describe that action or do that action and then we'll transcribe it as English language. So it's designed to walk you through that process. So even if you're a tester that's really never been comfortable using automated tools, it's going to feel like a tool that was built for you rather than a tool built for someone who's, you know, really comfortable with, you know, coding or as a developer.

Nice. How's it nowhere to run.

That's one of the things that you describe is before you click run, it asks you to the URL that you want to test in. So you give that. That's the one piece of missing information that's you need to give. That's not going to be in the test.

Now if it fails, does it give you any extra insights on does it mark anything in Zephyr Scale to say, hey, this failed or did these requirements weren't fulfilled or anything like that?

Yeah. So when you're first building it, it's going to give you feedback and that's part of where we use our Vision AI. So we're actually describe if we hit an error like say right off the bat, we'll describe not only hey, it's a failure, but we'll actually use vision to describe here's why we couldn't execute this step. And then later on as have your tests automated and you're running them in a cycle, a test cycle, it's going to automatically mark them as pass failed in the test cycle. So you don't have to do that manually.

So once again. So I guess eventually Reflect would just be like the execution engine and Zephyr Scale would be like the dashboard. People would log in and do everything. Is that how it works? Or would ever be someone would just have Reflect still, I guess it's too early to know. But like, what's the vision long term for this?

Yeah, I would say I see them as still complimentary even in the long term. You may have customers who for whatever reason just don't have the desire, I guess, to organize all of their tests in a test case management solution. Or maybe they're not on jira. Zephyr Scale is exclusively in jira. So I still see, you know, maybe a market for Reflect long term. But that said, if you could have sort of the organization and the reporting and the tight integration with jira of Zephyr Scale and the execution engine of Reflect. It does kind of make sense long term. As a married couple, you could think of it. So Reflect has previously has long integrated with the test case management tools and has allowed you to basically export all of your Reflect tests into your test case management tool like Zephyr Scale. So to the extent that that's valuable to you, I think that's going to be valuable to most customers. I think it makes sense to pair the two up. But we don't have long term plans to require you to use test case management tools. And Reflect is still. Reflect standalone, still works fine.

Yeah. And that, that's one of the things that we've, you know, we're still early at Smart Bear, but one of the things I've learned is that, you know, their approach to their suite of tools is that kind of allow you to mix and match things. It doesn't require you to go all in, you know, and maybe have to buy tools that you're never going to use. Which I think is nice because, you know, our experience has been everyone has slightly different processes and you know, we want to try to be where, go where our customers are and not force them to do a different process.

So yeah, I've used SmartBear for years. Years. I mean years sealed the gray. So they've been a great company. So I think it's a great, great match. Anything down the road. I mean, you guys seem like visionaries because you came up with the solution, seemed at the right time, at the right place and it took off. Anything you see on Horizon that other maybe kind of a transformative technologies on coming up that people need to know about or anything more about AI people need to know about or maybe misunderstand.

I think Todd probably has some ideas. I'll let him answer. I'll just add one little nugget.

Okay.

That I think, just to reiterate what I said earlier, that I think the killer apps for AI are when the AI does something for you, it's not when it just provides insights. I think. Sorry, I should narrow that a little bit. The killer app for software engineering, for DevOps, for tech, software quality is when the AI does something for you, it's not just insights. Obviously in the more creative industries, the AI, you know, can just provide insights or generate content. That's value creating. But I think the value creation occurs in software engineering and DevOps and test automation when the AI is doing something. So you really have to find actions or functions that the human is doing today. That the AI can do for them, to free them up to do, you know, higher order stuff. That's kind of my nugget.

Yeah. I would say. The two things that I think are really interesting is other places within your existing testing process that could be have this AI augmentation. So like, you know, if you think all the way from requirements defining all the way to, you know, things that you would do after deployment. Right. If you think about those and each individual action, there's probably some AI augmented actions that can make that particular part better. And the exciting thing about that is if you're an organization, you can look at the weakest part for your organization, that process, and try to get AI adopted for just that instead of trying to do the whole entire thing and change your process. The second thing that I think is really interesting is vision AI. That's. I think that's going to change a lot. It's going to allow things that are not. Have not been possible technically and make that possible. The universal interface could change a lot.

Absolutely. Yeah. I've been messing around with something for music called Suna AI.

I heard about that.

Yeah, it creates crazy. I mean, it's just nuts what it could do. So just applying it to creative things like that, I just see this being a real thing. I think a lot of people are kind of overhyping it or under hyping it and so I just think they shouldn't underhype it at all. But.

Anyway, random thought before we go. Any parting words of wisdom? You want to leave the Guild and what's the best way to find or learn more about Reflect with the Zephyr Scale solution coming up.

Parting words? No, I just would just like to thank you for again for having us on. Joe, it's always been a pleasure for me to speak with you.

Same.

And then to find Reflect. We're at Reflect Run, that's our URL on the web. And Smart Bear line of products is smartbear.com Zephyr Scale. You can find that in the Atlassian marketplace within jira. And yeah, we'll be releasing this to all Zephyr Scale customers in beta by the end of end of April.

Nice. Fitz, any potting words of wisdom?

No, just echo the thank you and yeah, everyone look out for that blue Run automated test button in your Zephyr Scale. And coming weeks we're excited to.

Very cool. Absolutely.

To get a lot of users with that.

Sweet. Well, thank you guys. Appreciate it. So guys, I know you. You go around probably showcasing this at different conferences anything coming up that if people are listening that they could check out maybe in person, actually see it because you did a demo on the webinar and then everyone's like, okay, now I see it. I think it's something you need to see to believe. So anywhere you're going to be demonstrating this awesomeness?

Yeah, we'll be at the Atlassian Team Conference at the end of April, so if anybody is going there on site, they also have a virtual conference component to it too. Feel free to reach out. We're happy to talk to customers or anyone curious about how our AI works.

Remember, latency is the silent killer of your app. Don't rely on frustrated user feedback. You can know exactly what's happening and and how to fix it with bug snag from SmartBear. See it for yourself. Go to Bugsnag.com and try for free. No credit card required. Check it out, let me know what you think.

And for links of everything of value we covered in this DevOps toolchain show, head on over to test guild.com P143 and while you're there, make sure to click on the Smart Bear link and learn all about SmartBear's awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything 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@test guild.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 solve a problem for the Guild community. I'd love to hear from you. Head on over to test guild.info and let's make it happen.