Mobile DevOps with Mav Turner

Intro / sponsor read

Get ready to discover the most actionable end-to-end automation advice from some of the smartest testers on the planet. Hey, I'm Joe Colantonio, host of the Test Guild Automation Podcast, and my goal is to help you succeed with creating automation awesomeness.

Joe Colantonio

Hey, it's Joe, and welcome to another episode of the Test Guild DevOps Toolchain Podcast. Today, we will be talking with Mav Turner all about Mobile DevOps. If you don't know, Mav is the Chief Technology Officer of DevOps at Tricentis, a 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 in N-able and SolarWinds, so he really knows his stuff. Really excited to have you 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.

Intro / sponsor read

Hey, if your app is slow, it could be worse than an hour. It could be frustrating. And in my experience, frustrated users don't last long. But since slow performance is 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 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 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.

Joe Colantonio

Heqy, Mav. Welcome to the Guild.

Mav Turner

Thanks for having me, Joe.

Joe Colantonio

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? How do you keep a pulse on what's going on? Is it because Tricentis 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.

Mav Turner

Yeah, exactly. 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, DataOps, 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 the processes internally, completely independent of the technology, but then also continuous delivery and whatever ecosystem they're just seeing 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 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 faced 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 and what they're struggling with because we'll talk on podcasts and some shows like this, the media will talk about the cutting edge and what everybody should be doing. But when you go back to you 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? Bringing those together is what I enjoy the most.

Joe Colantonio

Love it. What are they struggling with?

Mav Turner

Yeah. Today, I really want to talk about what they're struggling with through the concepts of mobile. But I will say there's still the broader struggle with I.T and development that has always existed as far as the constraints on budget and 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 A.I., but now the ability to leverage it 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, really want to focus on the mobile challenges. And when I talk with customers about how they're building mobile apps, were they are important, were they are not, some people say, 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 to giving the visibility, the testing. And we've really seen a big shift, particularly over the last 3 to 5 years of their traffic going to mobile devices and those mobile experiences, whether they're just providing the same web experience and mobile device or they're having a full made of app experience are really hard for companies to build applications around and test and get the quality, and rattle off all of the things now. But there are a lot of challenges with this area, particularly given the last several years where that shift of user behavior has really accelerated onto mobile instead of more desktop-centric.

Joe Colantonio

Absolutely. 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 3 to 5 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 more people going digital because of that and they're forced to not only hear about mobile, but actually, okay, now we actually do need a really smooth mobile development experience and a software delivery for it.

Mav Turner

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 the market. Everybody can feel what they're doing, the frameworks to build and test, 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 was, I think, surprising, really surprising the beginning was everybody was at home, so they should have been their laptops or personal devices at home. 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 or 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 are within arm's reach of those devices, they did change their behaviors drastically, probably largely because they're stuck at home for a lot of periods. So we saw that shift pretty drastically, which the 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? 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 the people moved into. 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.

Joe Colantonio

Absolutely. I also noticed before there almost was a lag in development in mobile. With automation usually focused on the web browser first and then mobile was kind of maybe third, a 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. Is that another reason why? I guess because more people are moving mobile, I've seen a lot of announcements, especially from Tricentis that really expanding their portfolio of how they can help developers and testers with the mobile development lifecycle.

Mav Turner

Yeah, exactly. We think there are still a lot of unsolved problems there where people are struggling with and there's a lot of opportunity to make improvements. We've acquired companies, we've built technology. Again, it's not mobile itself, it's not new. 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 instead of mobile 4th or 5th like you said, it's mobile-first or instead of after you've deployed their app and then everybody turns around and says, what about our mobile app? Or how does this experience on mobile? And then I don't know. Let's go make that app. That's part of the design requirements, the beginning of that conversation. How we deploy this. 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 not a time for that update to go live. And so that's very different than you controlling SAS infrastructure where you can push out whether that's a feature update or a high critical security issue. And with mobile, you build that, make the update, you push it out, you wait. And so that's why I hate I'll use this overused term of shifting left that quality story. What I mean by that is making sure that not just saying that developers have to do quality but pulling the testing cycle earlier in that process is super critical because when we talk about escape bugs and the cost of your bugs in production versus finding them earlier for a business that's very critical in mobile because not only does it take a while to get that app store to approve it and then push that applied for their end customers. The customers do their software updates. The platform updates that they're running on are moving faster and they're out of your control compared to 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, you don't own the stack of the user's device. 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.

Joe Colantonio

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. Does developers running in cloud earlier on for testing on devices?

Mav Turner

Yeah. Typically when you build mobile apps, you've got a local emulator, right? It's local device you run against one target device. Does it work? Yeah. Great push merge domain one of your processes. 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. Typically you're probably going to unless you're doing like React or Flutter, you're going to be if you're developing Native app, you're going to be in one specific ecosystem. Even if you're doing an Android application and you're 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 developer's like day to day activity, but we want to make it easy for them to pull in quality because that's the reality, right? We don't make it easier than but we continue the same patterns. And so that's we're trying to get better coverage every time you do a commit, whether you want to have a commit level, you won't 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.

Joe Colantonio

Nice. 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 and shift left, but is there certain infrastructure things that the cloud? How does that come into play? What do people need to be aware of? Like what can we do in 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.

Mav Turner

Yeah, I think a lot of things to think about are what type of device profile you didn't hit. Do you need to hit a real physical device or a virtual emulator or a simulator sufficient for your needs? Are you trying to test for network connectivity, low battery and 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, outside mobile world, you're changing devices quickly. You're changing between towers, networks, and bandwidth speeds all get drastically. You step to do 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 a web world and other traditional applications that are particularly challenging in a mobile world, and what do you want that mobile app experience to be? And I think that's where a lot of folks will start to say, Hey, you get our initiative, let's get it. Hire a team. 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 of the phone at a really high rate? Are our bandwidth needs very high, but our target user is in the low bandwidth demographic, right? How important is latency impact versus bandwidth? What is the application really need there? And are our users going to be in environments where that's practical? 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 you 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, this is software 101 understand your user, right? And with mobile, that just broadens the challenges a lot more than traditional applications.

Joe Colantonio

That's what I'm going to say. A lot of people pay lip service to the user experience in the web. Maybe they can get away with some 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 of the right country or the right kind of profile?

Mav Turner

Yeah, so that's the challenge. Let me 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 good visibility there like that has to come from your core business requirements. Are you targeting a 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. That's the business requirements understand the user or are they going to be in a highly densely populated first-world country, high bandwidth around wi fi all the time? The few times they're not, they're on 5G anyway. Those really matter. Understanding that is critical that comes from the business part. From the technical side, Google Analytics, if your app is web-enabled, that's fine. You gonna 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 applications 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. Whether you're thinking of that from a performance engineering perspective or you're simply thinking about it from the user experience in a normal mode, not kind of 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 was talked about earlier that we see in the market that historically, yeah, there was some API level information to get from the various OSes, but it just took a lot of work. And so typically you're not going to do that. But how we were running our products and how we were able to run these test runs were 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.

Joe Colantonio

Nice, is all this done through emulation? Back in the day, I started as a performance engineer, so we'd have to emulate like a board 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?

Mav Turner

Yeah, absolutely. So it's really fun actually to take it to play with all of that. So we have two different solutions. We have a physical device forum. So if you want to run your device one, 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 simple would say about where you want this device to operate, what hardware configuration do you want? At that high level, you start out with do I want Android or iOS? Do I want what version of iPhone do I want? And hardware and software running on that? So you could find your profile, the device that you want, and there are other characteristics that you can find, such as battery usage. Do I have a cellular connection or am I just using wi-fi? 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, you want to simulate being. It's less about being 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. Is this thing going to be on 1k salary 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 example?

Joe Colantonio

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

Mav Turner

Yeah. So I'll kind of come to like Dev and QA and uses and then the like. How do you plug into it a separate question? To me, this actually is the fundamental question about Dev QA shift left. It comes back to that. So the value of QA in my view is not the real clicking the buttons, particularly with a lot of the general AI capabilities, a lot of that can be automated. The value of the quality engineer, which is actually a lot of the more mature organizations 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 in those real-world customer experiences into the development process. That to me, when you're talking truly about quality, that's what that person adds to the process versus like, 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. Why don't they just have the developer do it all and hey, there's one person shops that were that's the case. But the value in that specialization and the value, 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 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. So that's to me, back to that rule. We could do a whole talk just on Dev, QA, shift left, 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? For us, there are 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 developers use it, some QA use it. In our ideal world, they're both using it and they're using it in slightly different forms. And the quality engineer is really pushing for, again, the automation that scale, that breadth of coverage, performance engineering components of it. And that's what that role is about in the developer role is making sure that as part of the pipeline and getting those results, we know how to interpret them. And so the short answer of how does this thing work? Is we actually, you just call it in your pipeline, runs those tests. Those tests are created in the UI. So a lot of the solutions Appium is one of the most common coded solution that 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 new 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 box, the PM, the business tester, some of these other roles to quickly offer, and it also allows the developer to quickly offer and spend their time coding on the coding the tests instead of coding or coding the product and set the coding test. And so that's the short answer. You build your test on 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.

Joe Colantonio

Nice. We've covered a lot so far. We talked about battery life, and device profiles of 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 move post-COVID, it seems like accessibility testing once again before was a lot of people pay lip service it, but now it seems like a lot of people are putting it front and center again. Could talk a little bit more about how maybe accessibility plays into mobile is there a 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 how do you help with that as well?

Mav Turner

Yeah, 100%. Most people, despite a lot of the upcoming industry 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 we ensure my app meets WACG 2? What does that even mean? What do I need to do? How do I educate my teams on what they need to do? I get a tool to help me. Most of my customers are still kind of struggling with that and needing help there. Little bit to our conversation earlier about here's the ideal world and here's the actual real world where we're at. And so those forcing functions of those timelines of different EU regulations, U.S regulations, if you're selling to U.S customers, typically they'll going to push you to to meet some of these standards much sooner. People are still struggling just with the website. And this again comes back to an 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 and that is kind of like how we got in there. Yeah. And so yes, we help there. We're trying to pull things through. Sometimes there's some overlap in particularly depending on how you 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 I would say that from my conversations, I'm sure there are examples out there, people who are crushing it, but most people aren't even able to talk about mobile yet because they're so struggling with web. But we realize that this can 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 the accessibility test, performance test, trying to simplify that back to like what we see in the market as opportunities to help customers with.

Joe Colantonio

You spoke a little bit about AI, can I help with this problem or how is AI built into your solution? How do you see AI helping address mobile testing as a writing Appium before is doing the coolest type of API that you mentioned earlier?

Mav Turner

Yeah, so it kind of hits everything. And by the way, just to be clear, and I'm sure people would 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 A.I. And particularly with generative AI, Large Language Models, the tools that it gives us. There are some really amazing use cases that we can capture now that are nondeterministic that we weren't able to really be successful at before. However, that doesn't mean that you should use that solution everywhere. And so there are oftentimes a very low-energy, low-cost algorithms that can be applied in a very deterministic solution. And that is the right answer. And then the reason why language is such a great way to advance us, there are more open problems that are nondeterministic, and that's where particularly a lot of the generative AI capabilities come into play. And so with that framing in mind, there are 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 in particular with generative AI in the context of mobile testing and accessibility testing is yes, there's ...... authoring IBM. 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 demos are awesome. And then you say, okay, so therefore, ChatPGT can just open AI can just create all of my tests. And they say, Well, actually when you want to try it together, make sure it doesn't get lost and hallucinate over here and follow the wrong chain over there. Think about like we've been doing this for a very long time. Blink crawling. That mean that's how you index the internet you call the links. AI can get just confused chasing some link off to nowhere. And so understanding the context of the application and where in the application that users are 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, ask ChatGPT and write me an Appium test to disable the cellular connection, look at works and like cool, how do I pull that into a full-fledged test story in my development? And so, yes, you 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 is an existing solution, it may actually be easier and better to use that because you're not going to pay because it's starting to get more expensive. I think the initial OpenAI ChatGPT world, everybody was like, Oh, look, I can use it, 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 costs 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.

Joe Colantonio

I love that it's 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. 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 their mobile DevOps?

Mav Turner

Yeah, absolutely. So we acquired 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 July I think was the official closing date maybe in 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 the emulator or simulator in your browser by just clicking a button and going through and really creating a test quickly. And so we felt like they have some really amazing technology there and they have a large customer base, right? So they had customers. We're 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, they got to go see their closet with all their old burned-out devices, kind of cool. And they started that way and they said, you know what, Thi1s is a lot harder than it needs to be less emulators and simulators. There's a problem they wanted to solve was the ease of use of authoring the test and executing the tests. And they really. So that's the important problem to solve. Back to your question earlier about so that QA, the nondeveloper types could help create the test and for developers, it could drastically lower the test time creation the test maintenance. And so they pivoted away from physical devices what to emulator in simulator upgrades and that allowed them to really focus on that core problem. And so they have a lot of customers and some of the customers I talked to said, they were really skeptical because they bought Waldo for the physical device. And then when Waldo went to virtual and emulator 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 are just were just slower and took longer. So where is a regression test maybe they can 8 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 back into your overall test strategy and making sure you understand what it is you're trying to accomplish there. But see how 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 into the rest of our mobile testing portfolio. So now it can author a test in Testim, and soon I'll be offering Tosca and execute it on the same virtual grid. And the next thing that's coming up very soon 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 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.

Joe Colantonio

Love it. And this is why I love speaking with vendors. I don't know how people can create these from scratch on their own without working with the vendors so it looks like you have everything covered from now 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 and one seamless type of solution. So sounds awesome.

Mav Turner

Yeah, I think so. Another area just around the overall topic of mobile and you talked about accessibility a lot. That was great. AI, the impact there. 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 engineer, team, product team I work with, we need more resources. We know 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 the same conversation with customers. I think, we talked a little bit about mobile is third or fourth now. It's kind of moving up the priority. But do we truly think about mobile first or is it mobile at the same time? 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 business logic is in the central service. 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 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.

Joe Colantonio

How do they do that? How they prioritize their needs then for their full development lifecycle, 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 plan from the beginning. Oh boy, now we need to go mobile. How do we bake that in?

Mav Turner

Your word, choice at the beginning is the key. When was 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 100% 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 don't try to swallow the elephant hole, 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, it's great to talk about here's your budget to your paper where we'd start, but the reality is that's probably not communication. 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 benefit for that first initiative. But if you can sell the leadership on the long term strategic value and what that opens up and flexibility to say this next one's not going to be cheaper. But you know what? When after that and when after that, and they'll get continuously lower costs as we expand and build this capability out. And trying to think through, I find, unfortunately, a lot of organizations, 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. And 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 with the information you had, and the budget, you had, and the constraints. We're all just trying to make things better here, I think.

Joe Colantonio

100%. Okay, Mav, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps/Mobile efforts? And what's the best way to find contact you or learn more about all these Tricentis solutions we talked about today?

Mav Turner

Yeah, I mean, I will do this office pitch. I do believe that Tricentis can help you in that journey for building an application you're struggling. Come to Tricentis.com. We've got some great mobile technology and mobile testing technology that can help you be successful with that pipeline. And again, I'm saying it because I do believe that we've built and we've invested a lot of time and energy, a lot of really great developers and 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 doing this. Reach out to me. I'm always available and always want to hear what's working, what's not, and how we can help.

Intro / sponsor read

And for links of everything of value, we covered in this DevOps toolchain show. Head on over to TestGuild.com/p133 and while you are there, make sure to click on the SmartBear link and learn all about Smartbear's, awesome solutions to give you the visibility you need to do the great software that's SmartBear.com. That's it for this episode of the DevOps Toolchain show, I'm Joe. My mission is to help you succeed in creating end-to-end full-stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers

Intro / sponsor read

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 at Testguild.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 love to hear from you head on over to testguild.info And let's make it happen.