Breaking Down DevOps Testing Silos with Danny Lagomarsino

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, are communication barriers and misalignment wreaking havoc on your testing DevOps teams? In this episode, we're going to uncover the secrets to achieving greater organizational alignment with Dan, who is a seasoned solution engineer from SmartBear. From overcoming obstacles to leveraging AI and testing, discover how clear communication, shared objectives, and innovative tools can transform your DevOps practice. Stay tuned for insights that could turn your team into champions for change. Check it out. But before we get into it, have you ever felt the frustration of siloed testing teams and the chaos of on misaligned goals? Then you know how crucial it is to have a centralized hub for all your DevOps testing needs. And that's where SmartBeer's test hub comes in. Test Hub isn't just another tool. It's a comprehensive solution designed to bring your testing process together. Imagine having all your test management, execution, and reporting functionalities integrated seamlessly. It's not about adding another tool to your belt. It's about simplifying your workflow and improving communication and driving your projects forward with greater efficiency. What's more, Test Hub's innovative interface and robust features make it easier for teams to collaborate and stay aligned no matter what they are doing. So whether you're just starting out with automation or looking to streamline your existing process, Test Hub has got you covered. Curious to learn more, support the show? Head on over to TestSkill me.

And see how you could transform your DevOps testing practice today. Check it out. Hey, Dan, welcome to the Guild.

Hey, Joe, good to see you. Thanks for having me.

Absolutely. Really great to have you on. I think one thing a lot of people I hear from on my podcast is dealing in silos still, even though a lot of teams are agile in communication, things like that. So I thought this would be a great topic to go over in, and I guess one of the things I have in my notes is one of the biggest challenges you've seen, I think I've seen as well for teams is they're trying to achieve greater alignment across their organizations, but they're finding it hard to do. How does one overcome that, do you think?

So I think, you know, I'm going to start by talking about, you know, breaking down communications barriers, and I Think it is something that is not just for aligning, you know, larger teams, but also for small teams. So I think me saying communication barriers is going to be a theme of this one, to be honest.

All right, nice.

But yeah, also that, you know, when we talk about, you know, greater alignment, you know, what we want to look for is, you know, the things without, like a shared vision. Right. We don't have objectives. Teams aren't going to prioritize their tasks properly. So if we can get, you know, if everyone can get on the same page that way, you know, anything that we need to do, for example, if we need to allocate resources, if we can get management support involved, it all really stems down to breaking down communications barriers, talking to not only your team, but also the other teams out there, making sure that, you know, even inside of your own team, you're not siloed. Because if you have silos within silos, then everyone's just testing with blinders on. And that's not a really great thing.

Absolutely. Yeah. I've seen organizations, it's almost like a mini waterfall where they're agile, yet they. They're mini waterfall and they don't talk to other teams. And I don't know why that is. And it's interesting. I used to work in a company where one team would sit across from another team and. And they want to communicate with one another as well. So curious to know, how do you then maybe it's a culture thing. How do you get the culture then to embrace this shared vision rather than just being a buzzword?

Yeah, and it very certainly can be a culture thing. You know, it's really kind of can be difficult, you know, if you are sharing that information, you know, maybe set up some cleared communication channels, maybe a centralized knowledge base or a database or something that anyone can come in and look for that information, ask those questions, encourage people to ask questions. You know, one of the things we do here at Smart Bear a lot is we say ask questions. There is no such thing as a bad question. So as part of my job, you know, that's what I do all day. I answer questions and people are not afraid to ask. So part of that is, you know, talking to people, making sure that everyone understands what's going on and also making sure that the processes are the same. So you can look at other teams and ask them what they're doing and then maybe try to align with what they're doing. How does that fit in with what my team is doing or what can I do to make sure. That that alignment between teams is a little bit better.

Once again, I'm just going to my personal experience we had creating a piece of software that relied on another team creating a third party software that we were then consuming. And then we came into these weird discussions like, what do we test since it's already been tested? Are we just testing the integration? Are we testing the functionality of the product that should have already been tested? Is that part of the process of saying, okay, what are the guardrails we have or what are our responsibilities for consuming this third party in house app that supposedly was already tested?

Yeah, and I think you want to, you know, even if, you know, you have a couple of teams that are testing maybe on different apps or different projects, you still want to be able to communicate with them to make sure that, you know, if there is an integration between the two applications, that that integration is being tested and met properly. Because without that, you know, you could, some bugs could get through. Obviously, you know, bugs cost teams money and, you know, you're losing the idea that you're going to be able to release this really great software. So for me, you know, when I think about, you know, releasing software and if my teams aren't aligned and if I don't know what's going on with those other teams, I get a little bit worried when that release comes around because I may know what's going to happen on my side, but I may not know what's happening on another team. So, you know, again, back to communication, back to processes.

And also I've seen it's hard to, for executives to know what the heck's going on because each team really isn't in sync with one another. So when the release is ready to go, they don't necessarily know the more holistic picture of what the heck's going on. Do you see that as an issue as well?

Yeah, I do. You know, and some of the things that, you know, I've seen is, you know, with, you know, maybe executive leadership having sort of one way that they want things to go, those processes of those goals maybe aren't shared entirely across teams. So it's really important for not only the executive team, but management and individual contributors to all be on the same page here. So it helps standardize those processes too, which is what, as an individual contributor, you can sort of establish too, and you can bring that to your management, you can bring that to other teams. You don't have to necessarily always wait on someone else in, on the top level, you know, making those decisions. You can make those suggestions and see, you know, if. If everything aligns.

No, I love that point. A lot of times I've seen the greatest impact on an organization coming from the bottom up rather than the top down. So that's a good, good point.

Yeah. Because when you think about it, you know, they're the ones that are doing the testing. They're the ones that are developing the software, so they're the ones that get to see everything. And maybe that, you know, you look at a management team or executive team, they may be just looking at reports, and the reports just may be numbers. It doesn't tell the whole story.

Right, right. So I guess this is tough. How do you get other testers to care what other teams are testing? For example, like, I just. I'm just getting graded on, not graded, but, you know, when it comes up to promotions, everything. How did you do on your application? Why do you care about maybe the team down the line, how they're testing?

Yeah, buy in is really important. You know, when you're trying to align, you know, there's a few ways that you could do it. You know, I think what I talk about a lot with my team here is continuously learning not only about the tool set, but about the tools and the other teams that you're working with or, you know, are available there. Because, you know, if you can learn, let's say, about a certain tool set that's within your team, and if that tool set is something that, you know, as you're scaling teams, you can scale into other teams, it's a really good thing to bring to the table. Finding that common ground. Right. Finding that thing that all of these teams can share and then build off. Because the last thing you want to do is you want to say, you know, my team does this better than your team, and then you're creating a competitive environment. And that never works. That really very rarely goes well.

That's true. But I've seen where, you know what the other team's doing. You're like, oh, I'm actually doing that. And you have like five different teams trying to solve the same problem. One testing team probably has a really good solution for testing something already. So do you see that as if you're in a silo testing team? Maybe one of the drawbacks of not communicating is you may be reinventing the wheel that may have already been solved by another testing team to try to solve what you're trying to test right now.

Yeah. Yeah, I could definitely see that. You know, you always want to say you know, what I'm doing is. Is the right way to do it. But again, you know, it really comes down to, you know, building that strong foundation between not only your team, but the other teams and trying to get buy in. You know, it's not easy. You know that it probably is one of the larger challenges when you're trying to align everyone, just getting everyone on the same page and making sure that, you know, everyone understands that, you know, maybe what you're doing is great, but maybe we can improve it. Maybe there's a way to be more efficient and that is, you know, through, you know, using the same tools, using the same processes, or even, you know, having this knowledge base where everyone can access.

Nice. Do you also see, you know, you work for a company that actually speaks probably with a lot of different clients, a lot of different industries, a lot of different verticals. You've probably seen it all. Do you have any examples of maybe how a project may have suffered due to siloed testing teams or how, you know, improving the alignment of the teams helped the product or anything like that?

Yeah, I think so. And without naming names. So, you know, at SmartBear, you know, we work with, as you mentioned, we are a number of different teams in a number of different verticals. And we work with smart large companies and smaller companies and some of the larger companies that, you know, we deal with. I will work with maybe one or two teams that are focused on automation, on testing, for example, and, you know, showing them the tools that we have at Smart Bear, they would then take those tools and they would implement those tools. But the issue there that they would have is, you know, maybe they have other testing teams out there that aren't using the same products, aren't using the same tools. Nothing's standardized. And that's really what I hear a lot. I hear, you know, we don't have any standardization inside of our organization. We have, you know, X amount of teams. They're all kind of doing their own thing. But if we can, you know, if we can get my team on board with one of your tools, it's successful, we can expand it. So it's always kind of with larger teams, it's always, we got to start small. We like to start small with one team, and then we can expand it out and. And, you know, I think it's a really good idea for larger teams. And it's something that I talk about with these teams quite a bit. And I think it's kind of the way to do it because, you know, let's say you do have a large amount of teams. It's, it's, it goes from, you know, being able to handle, you know, teaching teams and this process and these tools and then you're going to, you know, these larger rooms where you're lecturing everyone and just talking to people. And that really never really works out as well as you think.

So how do you get buy in then from people to do on more standards? Do you like a proof of concept, say, hey, we did this for this team. They're now able to do this quicker or faster. Like what is the benefit of. For that?

I guess, yeah. So during POCs, for example, you know, we will talk to teams and dependent upon, you know, the industry, I can bring in certain examples of other organizations that are using, you know, our tools, for example, to speed up testing. You know, typically what I'll talk to teams about, especially if they're manual testers going into automation, is I will ask them, you know, how long is it taking for you to manually test how many tests you're running and then sort of transition that and show them, you know, how automation and standardization can speed up testing. You know, the idea where I can simply say, yeah, if your testing takes three days manually, what if you use an automation tool and I can show you that it's going to take six hours? Those type of things, those are statistics, those are things that people want to see and those are the aha moments when talking to teams like that.

Awesome. So this is the DevOps Toolchain podcast. I'm just curious to know. Eventually people need to run these in a pipeline, check in and check out. And I would think the DevOps is even yet probably another silo team. What do you see? Is DevOps more of a, a culture thing or is it actually a separate team? And then all these testing teams need to then configure or get their testing somehow integrated into the pipeline in a way that's going to not break it for all the other teams that are using that same pipeline type deal.

Yeah, I've seen a little of both. I've seen teams that just create their tests and they'll hand it off to the pipeline and the dev teams and let them run the tests. I've seen teams where DevOps is involved in testing, but for the most part I would say, you know, DevOps, DevOps is definitely, you know, separate from testing teams. It's just sort of the way that the culture is going or the way that it's been. But now, you know, when you Think about the tools that are available for teams, you know, that are, you know, being easier to use, easier to implement, you know, more DevOps teams are getting involved in the testing side, which is really great because when you think about, you know, you're running your pipelines, you're getting your results, where do those results go? They go back to the DevOps team. Right. And what did they do with them? Right. If they don't communicate with the testing team to say, hey, there's some errors here, how do you know? And that's really what standardization, aligning the same tools and resources would help.

So do you see the DevOps organization or team being an accelerant to say, hey, here what we've seen work for other teams, Maybe you should try this approach as well?

Yeah, they certainly could be sort of a champion in those sort of situations. Especially when you're dealing with teams that maybe they're reluctant to change, maybe they're reluctant to try new things.

So that's a good point. So I see champions as being a way maybe to feel already possibly siloed in a large team. Getting more of the teams organized is having like a champion saying, hey, we should do this. Based on what I've seen here, probably, yeah.

And the great thing is, as I mentioned before, it doesn't have to be management, it doesn't have to be leadership. It can just be someone on the team that has this really great idea, has used this tool maybe in the past and wants to bring it into what they're doing now.

Love it. Love it. So I guess once someone has some sort of process in place, a lot of times people only work for the sprint. Almost like, hey, works for the sprint. Let's get it out the door. How do you help teams organize to plan not only for now, but also for the future?

That's a really good question. So some of it's going to be, you know, clarifying, you know, when those sprints are happening, the roles, the responsibilities of everyone, you know, I think, you know, there is this idea that, you know, some teams, they like to specialize, they like to have everyone in that team specialize in something. But with cross training, you know, you can sort of break down those barriers and make sure that, you know, as you're running those sprints that they're, everyone is on the same page because everyone understands what everyone else is doing. So it's sort of a cross testing or cross, sorry, cross training sort of situation where, you know, we're not expecting, you know, a QA to go out and, you know, actually, you know, fix the bugs in the application. But we are expecting, you know, the QA to be involved in, in finding the bugs, relaying that to the developers, and vice versa. You know, we want the developers to understand that those bugs, you know, they need to let the QA team know what's going on. And maybe without the proper tools and responsibilities, that may not happen. So making sure everyone knows what their roles are during the Sprint or even after as well. No. Is going to make things a lot easier for everyone. And then you can, what you can do is, you know, maybe if you're integrating or making some changes, you could do it, you know, from Sprint to Sprint, do it incrementally so teams aren't overwhelmed when they're being asked to maybe change processes, change tools, or even, you know, align with other organizations.

Yeah, I love setting up responsibilities. A lot of times, like I worked with a company, had eight to nine Sprint teams, and if something failed, the tester didn't know who was responsible for it to triage. So it's almost like if you have that in place to begin with, that would go a long way with helping pretty. Breaking down these silos, I would think.

Yeah, absolutely. And then you're dealing, you know, obviously, you know, with siloed teams, you know, you could be dealing with some resource strain too, you know, trying to figure out like, where, let's say, you know, you're trying to buy software and you need to know how many teams need the software. But maybe you don't know, right? You don't know these other, what these other teams are up to. So you're going to buy this software, you get X amount of licenses, and then all of a sudden you realize, oh, we don't have enough licenses, but our budget's blown up now what do we do?

How do you overcome that? I can see that happening a lot. Someone buys a product, vendor product, they're like, hey, this is great. And all of a sudden we need more licenses, it starts adding up. Is it then, like, how do you get past that at that point, though, if they don't have a budget, I.

Feel like that's a sales question.

Yeah, yeah, for sure.

That's a really good question. Especially in today's economic headwinds, it's a little bit harder to, I think, pull more money out of budgets and ask for more money, but it's always worth the ask. It's always worth putting in that request. And that's the nice thing about, you know, if you're A champion. And if you know you're showing success, you're saying, yeah, we have these licenses, everything's going great, we can expand to these other teams and show efficiency, so show improvement. But it's going to cost us a little more money. And the ROI is there in automation. Right. The more you automate, the more return on your investment.

So here's an older debate, I don't know how you feel about it is I love vendor tools. I hate reinventing the wheel, but I seen organizations say, oh, we just do open source and there's no cost with open source is the, you know, the kind of what they say and obviously there's a cost to everything. Do you see one or the other? Do you see vendors working with open source or like how do you see it now, how people view vendor based solutions and do they actually see now open source as, as actually having a cost, like a hidden cost associated with it?

Sure, yeah. And open source is, you know, it's great, it does have its benefits. But I think one of the drawbacks of open source is training. You know, let's say for example, you're using Selenium, you know, and not everyone knows how to use Selenium, but you know, using an automation tool, low code, no code, easy enough, anyone can pick it up. So I think, you know, and here at SmartBear we are open source champions, we do have several open source tools. But I think for the most part a lot of teams that I'm talking to, let's say they're coming into automation, they may have tried the open source route and for whatever reason it didn't work. It could be, you know, they don't have the technical Personas to handle, you know, writing those open source codes, for example, or whoever was creating those tests, for example, they left and they don't have anyone else that can come in and edit those test cases as well.

Once again, great point. I guess this maybe goes more towards enterprises where, you know, they have a lot of enterprise software that's hard to automate and they may go, we'll use open source and not realize, you know, this other tool may have been a better fit because you nowads still test desktop apps or SAP apps or even mainframe still when I worked in insurance. So that's another point probably you have to take into consideration.

Absolutely.

So I guess team siloing, is that normal then? Then obviously you're going to be siloed then how do you make sure that they, that even if it is siloed in the sense that they're working on this team, that they are still able to be part of the bigger, larger vision.

So, yeah, that's a really good question. So, I mean, obviously you get it. You need to build those strong foundations on those teams, dealing with, you know, obviously promoting that knowledge sharing. But also, you know, at the same time what you want to do is you, you really want to almost preserve team identity. And team identity is a lot different than being siloed. Right. So you have cultures in each team and everyone kind of works, you know, differently. For example, like my team, you know, we've been together for, I think at least three to four years. You know, our culture, our identity is very strong. We work very well together. And because of that we're able to go out into other teams and kind of tell them, you know, how we're doing, how we, you know, get together and how we work well together. And really it comes down to like, regular feedback. Right. And making sure that, you know, when you're dealing with alignment and when you're trying to balance like that specialization as well, you want to be able to promote like cross team collaboration as often as possible. And it could be something as simple as just saying, you know what, we're going to have a meeting with these other teams and just talk. You know, it doesn't necessarily have to be about the business, but it can be anything and everything. And building those relationships is really going to help you to expand, you know, alignment, make sure everyone's on the same page because, you know, honestly, you know, if everyone likes each other, everyone's going to work better together.

Yeah, I was going to ask how do you actually do that? Because you have a model that works, how do you get that message out? So you just set up meetings about the teams. Hey, this is what's working with us. We want to see what's working with you. Is it exchange or do you have some more formal, like maybe after a big release, you have all the teams to get together and say what worked and what didn't work.

Yeah. So typically it'll start, for example, my team will ask a lot of questions. We want to know, you know, what you're up to, how many people you have testing, for example, what tools you're using. And really the big question that I ask a lot to teams is, how's everything working out for you? And if you were to be able to do something better, what would that be? I like to call it unlike, you know, I do a lot of software demos. So when I talk to Teams, I like to say, you know, tell me about your present state. And then when they tell me about it, I ask them, you know, what would your future state look like? And I would sort of caveat it with, you know, in a perfect world, what's your perfect future state? Knowing that that's probably not attainable, but just tell me, like, where you'd like to be. And, you know, they would, you know, kind of talk to me about that and say, you know, we'd like to be fully automated. You know, some would, you know, say 90% really, 80% is really kind of think where you want to be. But, you know, it's nice to just to listen to them and tell them, you know, when they have these ideas, when they have these maybe guidelines that they need to follow, you know, we can tell them, we can sit there and tell them, yeah, there's success there, or there's not success there, or have you tried this? Have you tried that? So it's sort of always evolving. It's very dynamic, and it really kind of depends on, you know, the team we're talking to in the industry and, you know, what they're looking to get out of, for example, you know, automation.

So this may be a bad practice now, but when I started, a lot of teams had centers of excellence.

Yes.

Like a COE team that sat on top and was able to do all this and spread it and have, like champions go into each of the sprint teams. I don't think it's in favor anymore now maybe I'm wrong. If maybe it's back. Do you see that as a bad practice and that, like, why. Why am I not. Maybe it's just because biased or somehow of what teams I work with. I don't see COEs as much as we used to. And I thought there were a lot of benefits of having a good COE in place.

Yeah, it's. It's actually funny you mentioned that, because I was thinking about that this morning that I haven't actually talked to anyone in, I would say, 12 to 18 months about their centers or centers of excellence. It just doesn't seem to come up anymore. And I don't know if they don't exist anymore or if, you know, they're lying low. But yeah, for a while, you know, like I said, 18, 12, 18 months ago, it was something that we would focus on. We'd ask teams, you know, tell me about your center of excellence. And the most part, you know, a lot of teams, they would say, you know, it's small, we're Just starting out or we don't have one. So it's, I think for the teams that I've been talking to, you know, it may be something new to them. You know, like, for example, you know, trying to align all these teams. There's. There's so much that they're already established in that introducing new ideas may take a little bit of time.

I guess another point of view I might have is I speak with a lot of testers that are experts, so I assume every company has their stuff together, has automation in place. But once again, since you do probably speak with a lot of different companies at different organizations, is that true to. Is automation now the standard? Is it still something you need to teach before you can even get to a center of excellence? Because you need to start on square one sometimes.

Yeah, really good question. I don't know if I have the right answer for that. I do think that, you know, a lot of teams that I talk to are new to automation, especially with the tools that I support. But, you know, obviously, you know, I've talked to teams that, that are fully in automation. They're maybe using other tools. They want to see what else is there on the market, on the landscape. So I'm not really sure, you know, it may, again, as I mentioned, you know, it may be, you know, the size of the team, the size of the organization, what resources they have available to, you know, build out a coe.

All right, so is AI going to fix everything? I know I have a new show and I could have sworn Smart Bear released something called Halo AI. Could that help break down silos? Does it improve testing? How does that all work?

Yeah, and the thing about AI, you know, we talk about this a lot in Smart Brand, and what we talk about is our Halo AI. It's really our underlying AI capabilities, right? So what it is, it's not meant to replace testers. It's just meant to, this is the word, like the buzzword here, empower teams. Right? So, you know, that's really what we're doing with, with AI. We're injecting it into our products to help developers, to help testers build out these tests that are going to be more resilient, less flaky, and a lot easier to not only execute, but say, for example, identify objects. For example. You know, we do have what we call our test hub right now, which is a group of our automated testing tools that we have injected Halo AI in. So what we can do is, you know, we can do things like we can have simpler object identification and detection. One of the more difficult things that I talk to teams about is object identification and automation. You know, how are we. Or how is this tool identifying objects? And what if the object fails? What if we can't find it? Halo AI can replace that because it can make it a little bit easier to identify objects. We also have advanced visual regression testing, so it mimics the human eye to make sure that we're eliminating false positives. And we have a few other things coming too. It's not something that we just made up a word and said, yep, everything's AI. We're done. We're continuing to build out, you know, AI capabilities within our tools, and we're honestly really excited about it.

Very cool. So do you have any success stories how maybe AI augmented capabilities helped the testing team once again, without naming names or companies or anything like that?

Yeah, I think one or two. So dealing with, you know, larger corporations that are using enterprise software, like SAP or Oracle, for example, you know, we found some challenges within those applications to identify objects. Some of them are flaky, some of the objects are dynamic, and they just change a lot. And it's a little bit difficult. Some of our AI capabilities within, say, for example, Test complete, have been able to help identify objects if they change. They're able to notify the tester that the object under test has actually changed the identifiable properties. And do we want the tool to fix those changes? So what we've seen there is, you know, when teams are testing, they're not running into these roadblocks with this object changing with, you know, the erp, updating the software and changing everything. So the really nice thing about that is we're using that AI to help us not only identify the objects, but let us know if something's changing, let us know if something's taking a little bit longer to load or identify as well.

I must sound like a grumpy old man. Once again, once sat up with vendor tools and they were tightly coupled where I knew if I wrote this test and mapped to this requirement, and then in the end, I had a nice rapport. I had everything all in one place. It was beautiful. Now with open source, it's like copy and pasting and trying to get things to talk to one another. Yeah, and I think a lot of companies miss out on having like, this was like a centralized hub. Do you have anything similar to that? Like, I believe once again, I've been following Smart Bi forever. I saw something about Test Hub. Is that like a tool that could help if something like that is similar, that can help manage and automate and execute all your tests in one place to make it easier teams to be able to actually have insight into that. What's going on.

Yeah, so the Test hub is actually a handful of our SmartBear products. We have an automated functional testing tool called TestComplete and we have a group of tools that integrate with it. For example, Zephyr Enterprise, which is for test management. We have bitbar, which is our cloud based device farm, Load Ninja, which is our UI performance testing tool. And finally we have Visual Test, which is our automated visual testing tool. So what we're doing here at SmartBear is we're incorporating all of these integrations. You know, we're building out with, and also adding the AI side too, to make sure that everyone is able to use the same set of tools here. Because, you know, typically, you know, with vendor solutions, you know, it was always, you know, there's an automated testing tool, but also if you want, you know, a test management tool that's separate and you know, we need to talk, get someone else to talk about that. But now what we're able to do is we're able to, you know, present these tools as one unified solution. That way, you know, if you do need to manage, automate and execute all of your tests in one place, there's a really easy way to do that. So with TestComplete, you know, you're creating your test cases, let's say, for example, against, you know, maybe a mobile device, and you're running it through Bitmart. So you're, you're making sure your application's working in test complete. With bitbar, you're making sure your application works across all devices. And with Visual tests, for example, you're making sure your application looks good. And of course, using a tool like Load Ninja, you're making sure that your application is performing properly. So all of these things can now be done from one hub and that is test complete, which is really great and really what it's doing, right? We're saying we're getting rid of blind spots, right? We're making sure that we're covering more types of testing and we're able to pinpoint those problems easily, which is going to allow us to scale easier. And then of course comes back to just confidence in your releases, right? You don't want to be scared when you go to release the software that it's not going to work, that there are bugs. So you want to make sure that, you know, your testing is where it needs to be and the application is the best it can possibly be. And then, you know, we're fortifying it with AI to make sure that we're able to, you know, grab those processes, make sure that we're eliminating lengthy error prone processes that, you know, maybe would take up time if we're doing manual testing. So we've got a lot going on here at SmartBear.

Yeah, so that's a great. Another great point is maybe a team is siloed and they're doing functional testing and now they have a new story that has a performance criteria. And like now what? But you mentioned like Test Hub has tooling like Load Ninja to help with that. So would that help silo teams then break down, maybe having a separate team that just does performance testing to now open it up to more testers across the organization?

Yeah, I think it could. And especially when you think about, you know, managing test cases, for example, you take a tool like Zephyr that you know is simply going to store the test case results. For example, you can have, you know, multiple teams using Zephyr so everyone can see what everyone's doing in their releases, which is really nice because let's say you, you know, you have those teams that are working on separate applications, but maybe there's an integration there and you're not really sure if you're on one team, what's going on with the other team. But you know, if you're too afraid to talk to them, maybe embarrassed, you can always use the test management tool to go in there and get the information that you need. So it's really nice that even with siloed teams, you know, to get them on the same tool set with these tools, they don't necessarily need to use all of them, but maybe if, you know, one or two people in each team uses some of them, you know, and they can communicate back and forth and that's going to create, you know, more alignment within these teams.

So Dan, you mentioned this before, you're doing a lot with AI now and you said there's even more, but you didn't really, you didn't give us anything. Can you give us a little, little red meat or a little teaser maybe what's on the roadmap, what you see coming? Yeah, possibly.

Sure.

No promises, but yeah, yeah.

So what? Absolutely. So let's take a tool like TestComplete, for example. So what we've recently, what we're about to launch in beta for TestComplete is AI test data generation. So what this is going to do is if you are, if you do have that requirement to drive data through your application and you know, maybe you don't want to use a database table or an Excel spreadsheet, you can use the AI capabilities inside of TestComplete to simply say, fill out these forms with realistic values, for example, and TestComplete will read that and be able to fill out those forms as needed. That's just one little thing. We also have some AI powered API contract testing that's coming. This is going to help users contribute to delivering obviously more powerful AIs here. And then when we talk about one of our other tools called Reflect, we have a true codeless test automation tool. And with Reflect, we can leverage AI to not only identify objects, but we can also use because it does actually integrate with OpenAI. And what we're able to do there is use AI prompts to essentially ask the application and ask Reflect to do certain things just based on Freeform English.

Very cool. Okay, Dan, before we go, is there one piece of actual advice you can give to someone to help them with their silo testing DevOps efforts and what's the best way to find or contact you?

So the best advice I can give them is, you know, going back to the beginning. Communicate, talk, you know, you hear this not only in teletes, you hear this everywhere. Communication is the key to any successful relationship, you know, whether we're managing our own relationships or customer relationships or within the organization. So talk, you know, understand what everyone else is doing, be empathetic because, you know, we talk about being empathetic in software testing quite a bit, especially here at Software. Understand, you know, what the other teams are doing, what your own team is doing, and find a way to bridge that gap. Right? Figure out, you know, what works, what doesn't, and, you know, try if you can to come up with a plan. And as far as, you know, reaching out to me, I can be found on LinkedIn, found through smart Bear. I think that's probably the only two. Like I think LinkedIn is one of the, one of the only social media tools I use these days. But yeah, and for links of everything.

Of value we covered in this DevOps Toolchain show, head on over to test guild.com p157 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.