Mobile DevOps with Mav Turner

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with 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 Skill DevOps Toolchain podcast. Today we'll be talking with Nav Turner, all about mobile DevOps. If you don't know, Mav is the Chief technology officer of DevOps at Tricentis. Really cool title, which is a global leader in continuous testing. In his role, Mav oversees research, development as well as product growth and strategy to enable organizations to really accelerate their digital transformations by increasing software release speed. That helps you reduce costs and improve software quality, which is more important now than ever. And before joining Tricentis, Mav was the Vice President of Products at Enable and SolarWinds. So he really knows his stuff. Really excited to have him on the show. So listen up to discover more about mobile DevOps and what are some of the key challenges facing organizations today across mobile app development, testing and deployment. Especially in DevOps. 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 in my experience, frustrated users don't last long. But since slow performance is a sudden, it's hard for standard error monitoring tools to catch. That's why bugsnag, one of the best production visibility solutions in the industry, 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 get the context of where the lags are and and how to fix them. Don't rely on frustrated user feedback. Find out for yourself. Go to Bugsnag.com and click on the free trial button. No credit card required. Support the show and check them out. Hey, Mav. Welcome to the Guild.

Hey, thanks for having me, Joe.

Awesome to have you. So, while we kick it off, I'm just curious to know, as a Chief technology officer of DevOps, what does that mean? Like, how do you keep a pulse on what's going on? Is it because Tricent is so huge, you talk to a lot of customers, so you kind of get a feel for what maybe you need to focus your energies on?

Yeah, exactly. So I get the question about the title a lot because it means a couple of different things, and some people say that it doesn't mean anything. But what we're trying to convey with it is how can we build technology to enable teams that are practicing the latest and greatest from a software delivery perspective? So DevOps, obviously, is one of the things that we spend a lot of time talking about other trends, DevSecOps, data ops, all these things. But the whole point that really, when you boil it down to, is for teams that are practicing, trying to continuous improvement, trying to get better, continuous delivery, continuous improvement on their processes internally. Right. Completely independent of the technology, but then also continuous delivery and whatever ecosystem they're existing in, how can we help them provide tools and practices to be more successful? So that's kind of the scope of my work, but. But I'm glad you asked about the customer side. So we just finished up our roadshows pretty recently here. And so I got the advantage of going to a lot of different cities, talking to a lot of different customers, listening to a lot of different customers about the challenges they face and what they're focused on. So that's always a great period. It's a lot of travel for a short period. But it's great to just hear the customers what they're struggling with, because we'll talk on podcasts and shows like this, the media will talk about the cutting edge and what everybody should be doing. But then when you go, actually talk to practitioners and where they're at and what they're struggling with day to day, sometimes there's a gap there. Right. And we all know what we want to do ideally. But I've got these priorities, these projects, these timelines, these constraints. How do I actually make progress in my real job versus in the theory world? Right. So bringing those together is what I enjoy the most.

Love it. So what are they struggling with?

Yeah. So, you know, today I really want to talk about what they're struggling with in the context of mobile. But I will say there's still the broader struggle with IT and development that have always existed as far as the, you know, constraints on budget, time. We want more, we want to go faster. We've got new trends, obviously, with all of the new AI explosion that we've seen this year, we've had AI, but now the ability to leverage it and to quickly build on that has changed a lot. And so boards have questions, executive teams have questions, and there's a lot of misinformation out there, a lot of hype, and so struggling to deal with that. So that problem always exists and that's why this industry is so important. Right. To help educate everybody about where we're at, what trends they can leverage. But today I really want to focus on the mobile challenges. And when I talk with customers about how they're building mobile apps, where they're important, where they're not, some people say, hey, look, you know what? Mobile is not super important for us. It's not a big deal. But the vast majority of them are saying we're struggling giving high quality mobile apps, we're struggling getting the visibility, the testing. And we've really seen a big shift, particularly over the last three to five years of their traffic going to mobile devices. And those mobile experiences, whether they're just providing the same web experience to mobile device or they're having a full native app experience, are really hard for companies to build applications around and test and get the quality. You know, I won't rattle off all of the things now, but there's a lot of challenges with this area, particularly given the last several years where that shift of the user behavior has really accelerated onto mobile instead of more desktop centric.

Absolutely. So I was a full time automation engineer for many, many years and I was always told mobile, mobile, mobile. And I never saw a company really embrace mobile. But it seems like you said over the past three to five years, all of a sudden mobile really is becoming not only just a buzzword, but it seems like a lot of people are moving over. Do you think Covid had something to do with that? Are more people going digital because of that? And they were forced to not only hear about mobile, but actually, okay, now we actually do need a really smooth mobile development experience and software delivery for it.

Yeah, absolutely. So I agree. You go back 10 years and everybody's talking about it, and yes, mobile devices, 10, 15 years more powerful, starting to turn the market. Everybody's trying to figure out what they're doing. The frameworks to build and test and deploy and manage were very immature. And so those have continued to mature in that time. But we didn't really see that kind of market moment, I think, until when Covid hit. And what we really saw, which was, I think, surprising. Well, it is surprising to me. Anyways, everybody's at home, so they should just be on their laptops or personal devices at home, right? Well, it turns out that all of our behaviors change very drastically and we'd rather sit on the couch in the other room on a mobile device, a tablet, than go into our office or go to that workspace, that desk, wherever you're at, because now you're in a different mode and so even though people were within arm's reach of those devices, they did change their behaviors drastically, probably largely because they're stuck at home for a long period. So we saw that shift pretty drastically, which then now internal initiatives. Great. We're seeing all the traffic here. How do we better capture that? How do we provide a unique experience in this native app and take advantage of all the technology on this mobile device versus what we would serve up in a web app? Right. And so that's really prioritized in a lot of organizations, the quality and the importance of their mobile experiences beyond just kind of the mobile web mood that a lot of people moved into. So now we've seen a big push there because that's where the users are going. So that's where the other businesses are prioritizing, Right?

Absolutely. I also noticed before there almost was a lag in development in mobile. So when automation usually focused on web browser first, and then mobile was kind of maybe third or second in that chain of where development was going into. But it seems like a lot of focus has been on creating more solutions to stay up with the advancement of technology. So is that another reason why? I guess because more people are moving mobile that I'm seeing a lot of announcements, especially from Tricentis, but really expanding their portfolio of how they can help developers and testers with the mobile development life cycle.

Yeah, exactly. We think there's still a lot of unsolved problems there where people are struggling with and that there's a lot of opportunity to make improvements. You know, we've acquired companies, we've built technology. Again, it's not mobile itself is not new. Right. You mentioned this earlier. It's been around, but we do think there has been a massive shift in the market and the importance of mobile. So instead of mobile fourth or fifth, like you said, it's mobile first or instead of after you've deployed your app, and then everybody turns around and says, what about our mobile app? Or how does this experience on mobile? And they're like, I don't know, let's go figure that out. It's part of the design requirements at the beginning of that conversation. Right. How to deploy this. You know, one of the. You, you mentioned a lot about deployment earlier. Deploying a mobile app is very different than a web app that you control the infrastructure, you build your app, you push it up to the store, and then you wait and determine the amount of time for that update to go live. Right. And so that's very different than you controlling a SaaS infrastructure where you can push out whether that's a feature update or high, you know, critical security issue. And with mobile, you build the, make the update, you push it out, you wait. And so that's why, and I hate the, I'll use this overused term, you know, shifting left, that quality story. And what I mean by that is making sure that, that not just saying that developers have to do quality, but pulling the testing cycle earlier in that process is super critical because, you know, when we talk about escape bugs and the cost of, you know, bugs in production versus finding them earlier. For a business, that's very critical on mobile because not only does it take a while to get that app store to approve it and then push that app live to their end customers, the end customers do their software updates. Right. The platform updates that they're running on are moving faster and they're out of your control compared to, you know, I think historically, if you look at a lot of applications where you ran the infrastructure and you can decide when you wanted to update the infrastructure, you can decide when you want to update all the stack. You don't own the stack, we don't own the stack of the user's device. Right. And when they decide to update. And so that's why we think that there's a big gap there. And we have some really great technology we've been bringing to market to help close that gap. Still a lot more coming, but we do believe that we can meaningfully impact the level of quality of mobile applications in the market.

All right, so interesting point about shift left like you said then, because you're running on different devices and you just brought up like OS updates and all that, how do you pull it shift left? It almost seems like you have to do it in shift right production based on feedback and then pull it into the sprint. Is developers running in cloud earlier on for testing on devices?

Yeah. So typically when you build mobile apps, you've got a local emulator, right? It's local device, you run it against one target device. Does it work? Yeah, great push, you know, merge domain, whatever your process is. And what we're seeing is if you have the right tooling in that job, instead of just running it against that one target type, or instead of spending days trying to hit all these different targets, you can leverage some of these cloud capabilities that we've had to go run that job against all different target device types. So typically you're probably going to, unless you're doing like react or Flutter, you're going to be. If you're developing a native app, you're going to be in like one specific ecosystem. But even if you're doing an Android application and you're only going to target one device, the number of again, OS versions, the number of screen sizes, the hardware profiles, being able to test a wider variety of those earlier and simply is really how you get to the Shift Left mentality. Because we're not trying to change necessarily the developers like day to day activity, but we want to just make it easy for them to pull in quality because that's the reality, right. If we don't make it easy to continue the same patterns and so that's what we're trying to get better coverage. Every time you do a commit, whether you want to do it at a commit level, you want to do it every sprint, you want to run a daily, whatever your process is, being able to do that earlier on a broader set of device types is the key for quality. And that's really what we're trying to make easy for folks.

So when it comes to mobile development, is there any key things that people need to have in place to be successful with it? You mentioned running earlier in Shift Left, but is there certain infrastructure things, the cloud, how does that come into play? What do people need to be aware of if they're like, okay, we're doing DevOps, but we're mobile first, so how do we. Do we have to change anything than what we've been doing? Maybe if we had a more traditional web application.

Yeah, I think a lot of things to think about are what type of device profile you need to hit, do you need to hit a real physical device or is a virtual emulator simulator sufficient for your needs? Are you trying to test for network connectivity, low battery, you go to low power mode, what changes on the device and how does that impact your application? What happens when you lose connectivity in a web world? That state concept is important, but less impactful in a web world or sorry, mobile world, you're changing devices quickly, you're changing between towers, networks, bandwidth speeds all get drastically. You step into an elevator, we've all done this before. You step into an elevator, everything gets cut off. How does your application respond? And while those problems do exist in the web world and other traditional applications, they're particularly challenging in a mobile world. And what do you want that mobile app experience to be? Right? And then I think that's where a lot of folks, they'll start. They'll say, hey, get our initiative, let's get it. Hire a team. Great. You've got some great mobile developers. You're building your application and you're pushing the team to deliver features and functionality and you don't step back to say what's the user experience? What's happening? Is our application draining the battery on the phone at a really high rate. Right. Is our bandwidth needs very high, but our target user is in a low bandwidth demographic? Right. How important does latency impact versus bandwidth? What does the application really need there? And are our users going to be in environments where that's practical? Right. Are you targeting an application for somebody that's going to be doing construction out in the field, really far away from any sort of cell tower? Do they need to have more offline caching? Do they need to be able to be online the entire time? Those considerations I think are super important when it comes to building and defining the requirements for your mobile application. I mean, and this is, you know, software development 101. Understand your user. Right? And with mobile that just broadens the challenges a lot more than a traditional application.

That's what I was going to say. A lot of people pay lip service to their user experience in the web. Maybe they can get away with some of not really getting some clarity on what's happening. But how do people know then what their user profile is? Is it just Google Analytics? Is there anything else they can kind of look at to make sure they know they have the right mix or the right country or the right kind of profile?

Yeah, so that's the challenge, right? So I'm gonna give you two completely different responses. So one is business strategy, right? Who's your target user, what market, making sure you're aligned to all of that and having a good visibility there. Like that has to come from your core business requirements, right. Are you targeting a, again, like I'll use the field worker example, you're targeting construction in the middle of nowhere and what information do they need to be able to push back and forth? Does it have to be live or can they come back later that evening and then sync everything up and that's fine, Right? So that's that business requirement, understanding your user or are they going to be in a highly densely populated, you know, first world country, high bandwidth, they're on WI fi all the time. The few times they're not, they're on 5G anyway, so it doesn't really matter. Understanding that is critical and that comes from the business requirement. From the technical side, Google Analytics, if your app is web enabled, that's fine. You're going to get a Lot of stuff. But there's mobile specific instrumentation that we can provide and some of the solutions that we do actually specifically for this. What are the KPIs, what are the battery usage, what's the network usage? Bringing in all of those application and device specific metrics into that developer portal so you can see how your application is responding, what it's using, what it needs, and making sure you have those at your fingertips to understand and profile your application. Right. Whether you're thinking of that from a performance engineering perspective or you're simply thinking about it from a user experience in a normal mode, not kind of at a, at a high capacity timeframe. And so, yeah, so there's different instrumentation we can provide to the developers and that's part of the solution. And the gaps that I was talking about earlier that we see in the market that historically, yeah, there were some API level information you could get from the various oss, but it just took a lot of work. And so typically you're not going to do that. With how we were running our products and how we're able to run these test runs, we're able to gather a lot of that data. That makes it easy for development and QA teams to see how their app is performing and where they should focus on next.

Nice. So is all this done through emulation? Back in the day I started as a performance engineer, so we'd have to emulate like a baud rate of how people are connected to all that stuff. How do you emulate like battery usage or someone coming in from a different country on a different network? Is that done in your solution or how is it done? I guess the question, yeah, absolutely.

So it's really fun actually to get to play with all that. So we have two different solutions. We have a physical device farm. So if you want to run your device, run your app on a physical device, you can get some different metrics there. And that's where we have instrumentation on the actual device so we can see what's happening. You can also set profiles. Basically a simple way to say it about where you want this device to operate, what hardware configuration do you want? So at the high level, you start out with do I want Android or iOS? Do I want, you know, what version of iPhone do I want in hardware and software running on that? So you can find your profile, the device that you want. And then there's other characteristics that you can define such as battery usage. Do I have a cellular connection or am I just using WI Fi? Do I want to put it in low power mode, those are settings that you can put into that profile and then you have that profile set and then every time you run your test, it just runs against that same profile so that it minimizes the overhead whenever you're changing it. Yeah. Do you want to simulate being. It's less about. You can do IP geo changes to make it look like it's coming from somewhere else, but typically it's more about bandwidth. So you want to throttle that bandwidth down and define parameters just like you were talking about earlier. You know, is this thing going to be on a 1K cellular connection or are we going to give it 5G and give it everything or do you want to change that? Right. And introduce randomness into the bandwidth, which is a more realistic real world enterprise example.

So how do you bake that into the software development lifecycle? Usually it used to be a tester that would do all this, but it seems like if you really want to shift left, developers have to do this. How do they have to know? Or how do they know? Okay, now I need to emulate this or I need to instrument this so it behaves this way. I guess maybe we need a little know a little bit more about the solution. Maybe is this the Tricentis device cloud and how does the developer plug into it? I guess if that's the case, yeah.

So I'll kind of COVID the two like dev and QA and who's using what and then the like, how do you plug into it? A separate question. So to me this actually hits the fundamental question about dev qa shift left, it comes back to that. So the value of QA in my view is not, not the rote clicking the buttons, particularly with a lot of the generative AI capabilities. A lot of that can be automated in scale. The value of the, the quality engineer, which is actually a lot of the more mature organizations will tend to lean towards QE versus qa. But the value of that is thinking about that problem and making sure that they're bringing those requirements and those real world customer experiences into the development process. Right. That's to me, when you're talking truly about quality, that's what that, that person adds to the process versus saying, oh, the developer will just do it. All right, it's like, no, no, that's not the point. Now we put all this work, the developer can do everything. They can be the designer, the tester, the pm, the CEO, the. Why don't they just have the developer do it all and you know, hey, there's one person Shops that where that's the case. But the value in that specialization and the value of the specialization from that test perspective is they can spend a lot of time thinking about those different scenarios and making sure that those test suites are updated in that process so that when you're running you, so that again as part of your pipeline, you're running those functional tests, discover that immediately that same day, instead of waiting a month or waiting until a customer discovers it. So that's to me, the back to that real. We could do a whole talk just on dev QA shift left and all that, but that's the short version of it. And so and then shifting on to your question about like what does this actually look like? You know, for us there's two things. One, yes, we want to be able to empower developers, but we also want to make sure that QA have powerful tools as well. And so some teams use our solutions, the developer uses it, some the QA use it. In our ideal world, they're both using it and they're using it in slightly different, in different forms. And the quality engineer is really pushing forward again the automation, that scale, that breadth of coverage, performance engineering components of it. And that's what that, that role is about. And the developer role is making sure that it's part of the pipeline and getting those results, they know how to interpret them. And so the short answer of how does this thing work? Is we actually, you know, you just call it in your pipeline runs those tests, those tests are created in the ui. So a lot of the solutions, you know, Appium is one of the most common, you know, coded solution is what we would call it, where you can script out and code the interactions with the device. But we've created a UI to simply create, you know, click through codeless solution to create your test very easily. And that allows anybody to create it, whether that's the tester, the UX designer that built the mocks, the pm, the business testers, all these other roles to quickly author. And it also allows the developer to quickly author and spend their time coding on the coding the test instead of coding or coding the product instead of coding tests. And so that's the short answer. You build your test in our product, plug it into your pipeline, make a new change, have it execute the test script, get the results and decide what you want to do from there.

Nice. So we covered a lot so far. We've talked about battery life, device profiles, how developers and QA can really integrate into the cloud to make sure they're Testing things. One thing that I've heard a lot more about as well as we moved post Covid, it seems like accessibility testing once again before was, you know, a lot of people paid lip service to it, but now it seems like a lot of people are putting it front and center again. Can we talk a little bit more about how maybe accessibility plays into mobile? Is it different based on ui? And I guess if you're going across different applications and different devices and operating systems, probably a little more challenging. So do you help with that as well?

Yeah, a hundred percent. Most people, despite a lot of the upcoming industry, you know, deadlines about what's looming around the corner about being forced to meet certain accessibility standards. Most companies are still struggling with basic web accessibility testing. So they're trying to understand how can I ensure my app meets, you know, WACG2 1? What does it even mean? What do I need to do? How do I, you know, educate my teams on what they need to do? Can I get a tool to help me? So most of my customers are still kind of struggling with that and needing help there. A little bit to our conversation earlier about here's the ideal world and here's the actual real world or where we're at. And so those forcing functions of those timelines of different EU regulations, US Regulations, if you're selling to US customers, typically they're going to push you to meet some of these standards much sooner. People are still starting just with the website of it. And this again comes back to our earlier topic about how do businesses think about their web app versus their mobile app? And then when I kind of ask them about the mobile app, then their eyes kind of go, oh, we haven't even gotten there yet. And so yes, we help there. We're trying to pull things through. Sometimes there's some overlap, particularly depending on how you've built that mobile app. If you're just kind of servicing it up in a web browser versus a mobile web browser, you can kind of get away with some things, but it changes very drastically. And so I would say that from my conversations, I'm sure there's examples out there of people who are crushing it, but most people aren't even able to talk about mobile yet because they're so they're struggling with web. But we realize that this is going to be a challenge. We're trying to make it easy and just kind of bring it all together so that whether you're doing a functional test or accessibility test, performance test, trying to simplify that back to like, what we see in the market as opportunities to help customers with.

So you spoke a little bit about AI. So can AI help with this problem or how is AI built into your solution? How do you see AI helping address mobile testing? Is it writing app Inforia? Is it doing the codeless type of AI that you mentioned earlier?

Yeah, so it kind of hits everything. And by the way, just to be clear, and I'm sure people will give me a hard time for this, I'm a little bit, not a skeptic necessarily, but I'm trying to be more pragmatist a little bit about AI. And particularly with generative AI, the large language models, the tools that it gives us, there's some really amazing use cases that we can capture now that are non deterministic that we weren't able to really be successful with before. However, that doesn't mean that you should use that solution everywhere. And so there are oftentimes a very low energy, low cost algorithm that can be applied in a very deterministic solutions. And that is the right answer. And then the reason why language is such a great way to advance this, there are more open problems that are non deterministic and that's where particularly a lot of the generative AI capabilities come into play. And so with that framing in mind, there's other AI techniques that have been around for a while that are really helpful in this as well as far as pulling data back. But what I see particularly with generative AI in the concept of mobile testing and accessibility testing is yes, there's this autonomous authoring idea and we've done a lot of internal prototypes and you can go ask ChatGPT write me an Appium script to do X, right? And that demo is awesome. And then you say, okay, I want to. So therefore chatgpt can just OpenAI can just create all of my tests, right? And they say, well, actually when you want to string it together, make sure it doesn't get lost and hallucinate over here and follow the wrong chain over there, right? Like think about like we've been doing this for a very long time, link crawling, right? That's how you index the Internet, you crawl the links. The AI can get just as confused chasing some link off to nowhere, right? And so understanding the context of the application and where in the application the user's trying to interact with and where you want to test and ensuring that it continues those chains and doesn't get lost is the difference between, hey, I asked ChatGPT to write me an Appium test to disable the cellular connection. Look, it works. I'm like, cool, how do I pull that into a full fledged test story in my development? And so yes, it can write scripts for you. We're working on, we have already several prototypes on creating the codeless test for you already. And so that's exciting and we think we're going to have some new tech out there very soon, leveraging that. But so that's the net, right? It's exciting in some areas, but also a little bit of caution. Don't apply it everywhere. Make sure you understand where you're using it and the expected outcome. And if there's a existing solution, it may actually be easier and better to use that because you're not going to pay because it's going to. It's starting to get more expensive. Right. I think the initial OpenAI ChatGPT world, everybody was like, oh look, I can use it and it's free. And then you look at the scale for actual production use cases and you're like, oh, this starts to add up. And also just the environmental cost of the energy consumed by ChatGPT and some of these large language models is enormous. So we had to be mindful of that as well.

Yeah, I love that answer. It's all about context. It may not be applicable to what you're doing. So make sure you're aware of your situation, make sure even makes sense to use an AI or particular algorithm for your particular needs. Love that. So speaking of future of testing, I also have a new show I do every week and one of the news items that came across my desk, I don't know, even six months now, time flies, was the acquisition of Waldo. So can you talk a little bit more about when you acquire companies like Waldo? How do you fit that into what you already have to make it so it's seamless when people are trying to implement an end to end solution for maybe the mobile DevOps.

Yeah, absolutely. So we qualified Waldo. July or August, the exact close date. But I get you right time feels like particularly post after the start of COVID like things just compressed all along. So we acquired Waldo. Yeah, July I think was the official close date, may have been early August. And they had really been pioneering this zero footprint authoring concept and a lot of the analytics that we see around that, so being able to open a web browser with nothing installed on your laptop, load up a emulator or simulator in your browser by just clicking a button and going through and really quick creating a test quickly. And so we felt like they have some really amazing technology there. And they had a large customer base, right. So they had customers, were seeing a lot of success. Interesting story. I actually talked to some of their early customers. When Waldo first started, they actually had physical devices. And actually when we did the acquisition, I got to go see their closet with all their old burned out devices. It's kind of cool. And they started that way and they said, you know what, this is a lot harder than it needs to be. Let's do emulators and simulators. Because the problem they wanted to solve was the ease of use of authoring the test and executing the test. And they really said that's the important problem to solve. Back to your question earlier about so that QA and that non developer types could help create the test. And for developers it could drastically lower the test time, creation, the test, maintenance. Right. And so they pivoted away from physical devices, went to emulator and simulator grids and that allowed them to really focus on that, that core problem. And so they had a lot of customers. And some of the customers I talked to said, you know, they were really skeptical because they bought Waldo for the physical device. And then when Waldo went to virtual an emulator and simulator, they were skeptical. But what they found out was because of the speed of those tests, they could actually pull that earlier into the delivery process because the physical devices were just slower and took longer. So whereas a regression test may have taken eight hours against device, now they were doing it in under an hour. So they were really able to shrink their time and they really quickly got sold on that approach. Again, I think there's a place for physical and there's a place for virtual. It comes just back into your overall test strategy and making sure you understand what it is you're trying to, to accomplish there. But yeah, we bought acquired Waldo. Great team, great technology, great customers. And about a month after we acquired them, maybe six weeks, what we did was we took that core virtual grid and we plugged it in to the rest of our mobile testing portfolio. So now I can author a test and test them and soon I'll be offering TOSCA and execute it on the same virtual grid. And the next thing that's coming out very soon is, is the authoring in that same context. So instead of having customers go to the Waldo product and going over here, going over there, trying to pull it all together, so we've been able to move very quickly with taking their core technology and putting it there. And then we've got some exciting stuff coming a little bit later, more in 2024 around how to really continue to build on top of some of the innovative work they've done in other areas. So more to come on that.

Love it. This is why I love speaking with vendors. It's. I don't know how people can. Can create these from scratch on their own without working with the vendor. So looks like you have everything covered from. And I like how you said you're not replacing a physical device. It seems like it's part of an offering now where you have both options now in one seamless type of solution. So it sounds awesome.

Yeah, I think so. Another area just around the, just overall topic of mobile and we talked about accessibility a lot. That was great. AI the impact there. You know, I'm always very, very interested in how different businesses prioritize their different applications or needs or development. Right. We never have enough time or resources. Right. Every engineering team, product team I work with, oh, we need more resources. We need more resources. Great. And it's always the same question, okay, what are you trying to do? What are you trying to do? What are you trying to do? And I have that same conversation with customers and I think, you know, we talked a little bit about, oh, mobile was third or fourth. Now it's kind of moving up the priority. But, you know, do we truly think about mobile first or is it, you know, mobile at the same time? Right. It's. And that's an area that whenever I talk with development teams and I'm still seeing too much distance between the core application team or the web team and the mobile team. And I really think that as organizations mature and they lean more into services architectures, where the presentation that data in the web or the mobile doesn't actually matter because 90% of it is actually in this kind of the business logic, is in this central service. And I see a lot of teams struggle to get to that point because of how their overall business priorities kind of evolve and align. And so I'd love to see more of that in the industry where you can kind of decouple the delivery form factor. It sets the customers up for so much more success, allows faster delivery of services and security updates and new functionality. And so it's something that I think some organizations, again, they understand it not necessarily a new concept, but when we actually see where customers are at in that journey, they're still pretty far. So I just want to talk a little bit about the architecture of not just their mobile solution, but their overall solution and how that impacts their ability to be successful with mobile projects.

So how do they do that? How do they prioritize the needs then for their full development life cycle, including mobile, from the very, very beginning? Because a lot of times people are working on more enterprise applications that have been around for a while. So things change and they may not have planned from the beginning. Oh boy, now we need to go mobile. How do we bake that in?

Your word choice of the beginning is the key. So when is the beginning? Because was it 20 years ago before you were there? Was it five years ago? So look, if you're a new company and you get to start out, you tend to see these best practices more commonly deployed. You're a hundred percent right as opposed to a legacy environment. And I do think, I mean, I talked to some very large customers that have been able to start to kind of chunk out some of that work. And so, you know, don't try to swallow the elephant whole, figure out where you can partition out some of the bits and have that success. Because particularly in large organizations that have this more legacy infrastructure or long tail thing, you know, it's great to talk about, here's our blank sheet of paper where we'd start. But the reality is that's probably not going to be the case. And so as you do new initiatives, new projects, you get a new feature, say hey, we need to build this thing. Okay, great, what if we take this time to do it like this, it's not going to see a massive amount of benefits for that first initiative. But if you can sell the leadership on the long term strategic value and what that opens up and flexibility and say this next one's not going to be cheaper, but you know what, the one after that will and then the one after that and they'll get continuously lower cost as we expand and build this capability out. And trying to think through, I find unfortunately in a lot of organizations they lack that chief architecture kind of role and personally advocate for that. And if they do have it a lot that they get too far out. And so it's hard to get an architect that has the right balance of business prioritization. We need to make progress in the short term versus the ideal. And so that to me can be the key difference. But look for new initiative, new projects to start to move forward. Don't worry, nobody's judging you about what you're dealing with. A lot of times you inherited it and you made the decisions you made when with the information you had and the budget you had and the constraints. So, and you know, we're all just trying to make things better here, right?

100%. Okay, Matt, before we go, is there one piece of actual advice you can give to someone to help them with their devop mobile efforts? And what's the best way to find. Contact her, Learn more about all these Tricentis solutions we talked about today.

Yeah, I mean, I will do this selfless pitch. I do believe that Tricentis can help you in that journey. If you're building an application, you're struggling, come to tricentis.com, we've got some great mobile technology, mobile testing technology that can help you be successful with that pipeline. And I do, you know, again, I'm saying it because I believe it. I do believe that we've built, you know, we've invested a lot of time and energy, a lot of really great developers spending a lot of time making things better, trying to make things better for themselves and for you, the listeners. So please give them a try. And you know what, if we're missing something, let us know. I'd love to talk to anybody that's hearing this. You know, reach out to me. I'm always available, always want to hear what's working, what's not, and how we can help.

And for links of everything of value we covered in this DevOps toolchain show, head on over to test guild.com P133 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 testguild.info and let's make it happen.