Mobile Test Automation is Broken. Here’s How QApilot Fixes It

Hey, if you've been in testing more than 5 minutes, you know mobile automation is the thing people talk about but quietly avoid. Web testing tends to get all the love, all the tooling, and all the innovation. In mobile, you get Appium, and that's usually pretty much it. So when I came across QA Pilot and their co-founder Aditya, I had to get them on the show. These guys are doing something most tools don't bother with. They built a mobile-first autonomous crawler that was purpose-built from mobile from day one, not bolted on as an afterthought. It maps your app like a sitemap, handles popups on its own, generates test data on the fly, and yes, it even takes on Flutter, which as you probably know, has been a nightmare to automate for years. But what really stood out to me in this interview was how they think about the tester's role in all this. No AI will replace you, hype here. Aditya makes a case that the testing mindset still matters and tooling just handles the grind. So you could focus on the edge cases that actually need your brain. So whether you're a mobile tester at a big enterprise struggling to keep up with device coverage, or you're just tired of watching web automation get all the innovation, this one's for you. Check it out. Hey, but before we get into it, I wanna give a quick shout out to today's awesome sponsor, QA Pilot. If your team is constantly playing catch up on mobile testing coverage, running the same sanity checks across a dozen devices, missing releases, Cutting scope just ahead of deadline? That's exactly the problem they solve, especially if you're also testing Flutter. Instead of hand coding every test case, QApilot's crawler goes through your app the way a real user would and builds tests automatically for you. Your team stays in control, but the tedious stuff gets handled automatically so you can focus on the edge cases that actually need a human brain. So be sure to check them out and support the show using that link down below. Hey, welcome to the Guild.

Thank you, Joe. I'm very happy to be here.

Awesome. Great to have you. Really excited about this. A lot of times when I talk to someone, it's about, you know, web testing with AI. And what I really like is you're really focusing on mobile. So I thought before we get into it, maybe you could walk me through the exact moment you realized existing tools weren't really cutting it for mobile testing.

Awesome. So I'm glad you're starting here, right? So, uh, QA Pilot, uh, the two of us co-founders, me and Chetanya. Chetanya runs a company which builds mobile apps for mobile carriers, telecom operators. And, uh, that's when, when he was trying to implement test automation in the company, that's when he realized that all the tools are web-first. And, uh, going and essentially The web is probably the bigger market. So when you start doing web first, you try to extend what you've built for web into mobile. And that doesn't work. Mobile is its own beast for a variety of reasons, starting with the fact that you can't do mobile testing on emulators. You need real devices. The kind of locators, the XML versus HTML, there are a lot of differences, right? And also the number of tools which are available for mobile versus web is different. So web, you have, you can do, you even open source, you have Playwright, you have Selenium, et cetera. For mobile, you have just Appium, right? So we realized that, okay, there's a market here, there's nobody really addressing it. And if you're hyper-focused, yeah, we could create a niche for ourselves.

Love it. So what's wrong with Appium? People tend to love it, hate it. Like, was there any technology you tried with Appium and you're like, okay, this isn't going to work for us?

We love Appium. We love Appium. Just that there's no choice and the amount of changes into Appium and the commits in Appium are almost an order of magnitude less than you have for web tools. So it just doesn't move fast enough to keep up with what's happening in the world, right, for mobile apps. So for example, and this is something we focus on from the beginning, is Flutter. Flutter support within Appium is very poor and nobody's really solving it. So we then gone and built some middleware, which will help Flutter apps be tested on our platform. So it's stuff like that, which makes, uh, testing for mobile apps not as seamless as web applications.

Absolutely. Yeah. I noticed a lot of people do flood to, to get frustrated with Flutter. Um, so can you maybe give some, maybe, uh, like a little detail around like why, uh, what, what makes Flutter so hard to automate? Is it the identifiers? Like, and how do you work around it?

So it starts with genesis of Flutter, right? So Google, the way they started building and evolving Flutter, just the whole accessibility tree and the widget tree, the way it's built is not compatible with Appium. And now Appium needs to adapt to the way Flutter apps are built, render in real time. And that's just not happened. On either side.

Awesome. Got it. All right, so what makes you different? I was going through some, like a PDF I found online, just trying to learn more about your technology. There's something about the crawler. What is the crawler? You call it autonomous, I guess. Like maybe let's break it apart. What does it do? What makes it different from what we have already?

Yeah, so what we have, our view is, We, we crawl the mobile app and interact with it the way a real user would while creating test cases, because that also allows us, when you're interacting with it like a real user would, you then capture a bunch of other information regarding network traces, memory, etc., which help you really analyze how the app would work in the wild, right? So what we did was we said, let's go and find, actually what we said was, let's go and find a mobile app crawler because there's so many web crawlers. There must be a mobile app crawler out there, which we could use. And then we realized that there's just not, there's no mobile app crawlers in the, uh, out there. So we ended up having to build one and that's really our intellectual property now. So we have a crawler which goes into your mobile app. We upload your mobile app, goes into it, then clicks page by page and then creates a sitemap of sorts. And that allows us to then create test cases autonomously, which is why we call it autonomous, but also creates a as a ground truth for all our agents to work on top of.

Gotcha. So random thought, you know, I've been doing this for 25 years plus. A lot of people talk about mobile testing, but for some reason it seems like a niche within automation. Do you see that? Do you think it's because it's so hard to automate that maybe people don't focus in on it or they don't, they get turned off by it? Like, do you see that as well? Or do you see maybe with this tooling that you're creating, maybe it'll open up now people to really embracing mobile testing more for automation?

Yeah, so the customers we speak to, right, they, I think they're genuinely struggling with the tools which are out there. And the amount of effort which is taken, especially because we work with reasonably large enterprises, right? People who have millions of customers who use their mobile apps regularly. Mobile app needs to work on multiple OSs, multiple device sizes, and so on, right? That's really our customer target, right? ICP. And we see them struggling because they have to test on multiple devices, the same test cases, and they just can't keep up. So it's essentially what you're doing is you're to hit timelines, you're reducing your scope of what you're able to test. And that's really what we want to solve, right? One of the things we want to be able to solve is for you to be able to do your main tests autonomously. So our pitch is you do your sanity testing autonomously on our platform, and then you can focus your energies on all the edge cases and all the other things you require. To improve your customer experience.

All right, so you said autonomous. Sometimes people hear autonomous, they're like, oh, I don't need to do anything. I click the crawler, it does it all. Is there— where does the human come into play here? Is there any point within that crawl of an app that it could miss that maybe a flow does require a human to help jump in?

Yeah, so there are multiple points in which a human comes in, right? And we don't believe that the whole hype that testers won't be required and all of that, right? We firmly believe that the testing mindset is required and the role of the tester will change. So the way we think of a tester is a tester— a crawler is essentially a tool for the tester to do things autonomously. So while the crawler is actually working on your mobile app, you can actually see exactly what's going on. And the test engineer can interact with the crawler to make it go in certain directions. Also give it inputs and also change some of the decisions it has made if it's made a wrong decision, right? So all of that is possible within the crawler. I could potentially show you a quick screen grab and then, yeah. So what we do is we go into your crawler, into your mobile app and then create a graph of this sort. This is a knowledge graph on which the rest of our tool works. Now this knowledge graph allows us to create a sitemap. Of this sort, right? And our aim at this point is to get to all your sanity testing, all the positive test cases, which in most of our customers' cases tend to start from your home screen. So that's exactly what you see here. From the home screen, you see a bunch of journeys starting, and a crawler is able to go through all of them autonomously and then create these journeys, right? And that's pretty much how a crawler works.

What happens if you get like an error message or a popup or a network delay? And it's crawling, does it stop? Does it flag it? Like what happens?

So we, so we have a bunch of agents on our platform, which the crawler has access to. So one of the agents is essentially a popup handling agent. So the only thing it would do is it would go look at every screen, look at whether there's a popup and figure out how to get rid of the popup. So we do handle popups autonomously. We also have a test case, a test data generation agent, which goes into your app. And if there's some test data to be added to move forward in the application, it will generate the test data on the fly. You also have an option to give test data. The quality engineer can give the test data to the crawler and it'll use that. If that's not available, it'll generate test data.

You know, when people talk about this, there's two ways I've seen vendors do this. You have like a generative approach, use GenAI to help the tester. Right here is my mobile app. They're working with AI. They're getting chatted up by AI, getting coached up, and then you have this new way that more companies are going towards is autonomous. So when you say agents, like, what does that mean? Does that mean like the tester just says, here's my mobile app, sits back, you have a crawler agent that does it? You said like, I think I, you have like a network of agents, and then if it pops into like, it has a popup, it does instance and it calls a popup agent. If it has like maybe data it needs to input, it has a data agent. I know I'm making that up. Like, can you talk a little bit more? What are these agents? How does that work?

Absolutely. I'll show you I'll show you how they work. But first, I think I want to address our design philosophy with AI. And when people say AI, people say autonomous, you have a view, especially given LLMs and how they proliferated into our lives, that you have a text box and then you're telling the agent or the system what to do. And our view is text boxes have their place and they're good, but they're essentially the design choice of last resort. So we go to a text box only at the end, right? So we, we have primitives. Our primitives are BDD formats. We have the ground truth, which is our graph. And we have a human in the loop, which allows us to make sure that the crawler is doing its job. And I'll show you how all of this works. First, I'll show you our architecture. And then I'll show you the product itself. And then we can take it from there. Yeah. So what we have is this, right? So most testing platforms have a recording, execution, reporting module. What we've created is a new generation module for mobile apps, which then creates this knowledge graph. And on top of that, you have a bunch of agents, right? So you can have a monkey testing agent, you can have an accessibility agent, you can have a test data generation agent, you can create test cases and so on. Now, once you also have the knowledge graph, you can also bring your own agent. So if an enterprise has their own, uh, specific use case which they want to test, they can create an agent on top of our knowledge graph.

Now, before it does the crawling, do you feed it requirements? Like, like, how does that work? Is it, is it just completely random crawling and just understanding the application? How do you get the best results?

No, that's a great question, right? And I'm glad we're spending time on this because I was talking to people who've built web crawlers and the problem with web crawlers is because you can crawl so quickly. You essentially end up creating way too many test cases and it goes all over the place. So our, our, what, when we started building this, one, going through a mobile app takes time to go from screen to screen painstakingly. Then the other thing is we want to be, like I said, our pitch, our goal was to create your positive test cases, right? Your sanity testing and we want to complete that. And so the way we thought about it is once you get into a mobile app, the first thing you need to do is find homepage. So what our crawler does is does whatever is required in that particular page to get to the homepage. So we use LLMs and we do some context engineering on top of that and say, okay, you have 10 things you can do on this page. What is, what will be the action you take to get to the homepage the fastest? And once we get to the homepage, we recognize the homepage. We have a homepage recognition model, which recognizes homepage. And from the homepage is where all the journeys start. So then we do a breadth-first search and a depth, uh, uh, go into depth on each of the journeys to create the sitemap I just showed you. Yeah. So we looked at booking.com, right? So now this is an output from booking.com. Our crawler has gone into booking.com, has done a bunch of things, and it's created this sitemap, right? So if you see the raw crawler flow, this is what it would look like. It would go in. It, there'll be a start page, there'll be home dashboard, and then in every page, we'll decide the first page, like I said, is to find home node. Now on this page, there are a bunch of things a crawler can do, but the crawler decided to click X because it figured that that's the best way to get to a homepage. And once it gets to the homepage, it recognizes this homepage, then it does a breadth-first search of, you can see the circle here, right? All the items which are there, and then it goes into depth on each one of them. Finishes this activity graph. So this is essentially a way of quickly finishing your autonomous testing of all your sanity cases. So even if your app changes, we're able to finish the autonomous testing for sanity cases. Again, the view is that might be 10-15% of your test cases, but these are test cases which are most important. These are test cases you want— might want to run even in production every day, right? And our system is able to adapt and go forward. So yeah, these are all the test cases. We captured a whole bunch of information. And then also once we have the crawler, right, we can crawl more from a node. So for example, you can go here, you can say crawl more, and it suggests test cases to you. Maybe something's not already crawled, it can crawl. And this is where the beauty, I think, of our platform and makes it great for things like migration, consistency, and so on is that till now you've not seen any text. The first time you see text input, But this is in BDD format and the crawler has created the BDD format autonomously. Now, if I think something's wrong, I don't want to put New York and I want to put Cincinnati or Nashville, I can change it here and the crawler will take this as the input and go forward, right? So one is the human in the loop at multiple places and the fact that we go to the BDD format. For getting the consistency in the product. The next thing where human in the loop comes in is here, right? Let's say for some reason it detected the homepage incorrectly. In this case, it's correct. Let's say it detected the homepage incorrectly and this is the homepage, right? I can go and say, set this as homepage as a quality engineer. And then it will treat this as a homepage and do whatever it did in the other, uh, uh, in the other homepage by doing a breadth-first search and a depth-first depth to go into each of the test cases.

So I'm just curious to know, as it's autonomously crawling, are there issues you could find on the fly? Can you watch it and go, wow, that's an issue? Or it flags it and you go, I didn't know that, like it's 10 screens deep, that's an issue.

Awesome. Yeah, great question. So I'll just show you, I'll just share my screen again. I'm glad I'm getting to show so much of my product today. So while it's crawling, right? What it does is it, we do a whole bunch of WCAG tests, right? So let's say we go here, it goes and checks a bunch of things. So for example, color contrast is not good here, right? It's highlighted that. So you don't, and all of this can be downloaded and given to your design teams, your development teams without the test engineer doing a lot of work, right? It also checks whether there are any elements which do not have resource IDs, which is a problem for automation. It also checks the time taken from screen to screen, right? And also where the time is taken. So you can actually go and let's say do this and say, okay, these are screens where it's taken more than 2 seconds. Why is it taken more than 2 seconds? What was happening in the background? Right? So you can do a whole bunch of these tests autonomously while it's, while it's scrolling. Now, if you have the debug build of the app. You can do a lot more. Let me just show you this. So what, once we have the debug build, right, we're able to capture a lot of information from the debug build and match it to the app itself. So here you're able to see as the test cases have been executed, how the CPU changes, how the memory changes, whether any of the frames which have come in are not as per the approved FPS limit and so on. But the cool thing is here. Let's say you have the CPU, right? You see CPU spikes here. You want to see in which screens the CPU spike has happened. Screen A to screen B. You can check that. It's all available for— to be shared with the development team, the SRE team. So you're able to quickly identify things like CPU spikes and potentially even memory leaks, right? So we're able to do a whole bunch of things while we're autonomously crawling and executing the test case. All right.

So how do you handle, you know, devices? They all have different flavors installed on them. Does it tell you, okay, like, where can you run this? Do you have your own cloud? You run it on other people's clouds? And does it tell you, okay, it runs fine, performance is fine on these 3 devices, but this, this OS device combination is kind of wonky?

No, great. Yeah. So yeah, so we use device farms. So there are 2 ways to run your test case on our product. We give an EXE which you can run on your laptop desktop and connect your local device to your laptop and you can execute and record all the test cases using that. But our preferred way of working is through the device farms, right? So we integrate natively into BrowserStack, LambdaTest, TestMule now, Sauce Labs, and so on. And you can, we picked devices with OS versions there and we run it on multiple OS versions. and we're able to tell you that that test case has failed on this Android version on this device versus another device.

Oh, cool. And I assume once it gets that initial knowledge graph, it becomes smarter over time. Is that true? Like one person can fix it and then automatically anyone else that runs it or automatically picks up the fix and all the crawls that has the test, I assume.

Absolutely right.

Right.

So there are two things there. One is. The nav graph and the BDD format of getting from place A to place B. Now those become the ground truth when the app changes or when something we don't understand happens, right? And that can happen with mobile apps, right? And you alluded to that earlier in the conversation as well in terms of things can change in the wild, right? And so we use both of them to kind of get everything back on track. And especially the BDD format is a way of getting from node A to node B. And that allows us to then go from version N of that to version N+1 seamlessly and tell you which test cases have failed, which journeys are the problem. Now, once we also have the knowledge graph, there are a bunch of other things you can do on the knowledge graph, right? Because once you go deep into, let's say, mobile apps, we see that, and I've heard a couple of your guests talking about this, right? Anand from Rivian and Tanvi, Tanvi spoke about it from LogMiner, the need for SRE and QE to get closer, right? And we see that. And the knowledge graph is a great place for that to happen, which is you map out all your main journeys and you run them over and over again and map them with your observability traces. So it's a great tool for SREs also to run agents to check if any of your metrics have changed over a period of time. The other thing we do is from a device design perspective. So we look, we're looking at your design system and seeing whether every node is performing correctly on different types of devices. So you're able to actually, the knowledge graph allows you to kind of communicate with the rest of the organization because everybody's on the same page in terms of how you're looking at the mobile app.

Back in the day when I started performance testing, we used to have something called like a business process agent. I just have to install it on a machine, send it out to someone in the field, and they would just run like a sanity smoke test in the wild on their actual network in production, basically. And it would flag things. So it sounds like if you have telemetry installed and could you run this almost like as a sniffer in production, just to make sure sanity, everything's working as, as, as expected with your SRE team. Does that make sense?

Absolutely. And that's where we want to go with this, right? Because what we are seeing is this, uh, the, and this really are how we see the end state of our product, right? Uh, we want to focus on mobile apps. We think there's an opportunity today, but the bigger trend is that the development cycle, development release cycles for all kinds of software is changing. Uh, increasingly dev, QE, SRE are overlapping. The release cycles are collapsing. The last time this happened from waterfall to agile, a whole bunch of new tools came in. We believe that there's an opportunity to be that tool for mobile apps going forward. And we, so what we see is that even if everything changes, there's a release manager in every organization who's responsible to make sure things are fine in production, who's signing off. So we are building all our tools for that person. So we have a security testing for scan for that person before they upload the app into the App Store, checking what the App Store would check ahead of time, right? So we do integrations with your observability platform and mapping so that any critical flows, you can check if the observability trace, the metrics in the observability trace have gone off limit, right? So that's how we think about what we are building. We want it to be an overarching quality layer on the whole mobile app as DLC.

Love it. And it sounds like you're building for, for it to be extensible. I guess if I'm going back to that other screen you showed, I thought I saw like a bring your own agent. So it seems like you're making it so that like, even if you haven't thought about it now, you're able to integrate it pretty easily, I'm assuming.

Exactly. Exactly. So, uh, we have a use case because increasingly what happens is, uh, in most, uh, uh, enterprises, large enterprises, uh, dev testing business kind of take, uh, the most amount of focus and then the other stakeholders are left behind. An example is the legal or finance stakeholder who wants to do an audit in an e-commerce app, whether the right disclaimer is available for each product. On the screen, right? Now, a stakeholder from finance or audit team can come into our product, look at the knowledge graph, and build an agent which goes in and checks whether the correct disclaimer is placed below every product on their mobile app, right? So these are things which can be built. Once you have the knowledge graph, you can bring in other stakeholders to take care of their use cases, which I mean, in today's world, it's really difficult to get that done in any organization, right?

Absolutely. A dumb example, back in the day, we used to, I had a company that rebranded and we had to change the logo on every screen. We had to check every screen. Like you mentioned LambdaTest, they mentioned they changed to TestMew. Maybe like you could create, hey, check this mobile app, make sure all these pages have the correct logo. I don't know, making something up, but.

Exactly. And it's essentially the way we think about that level of testing is So there is, so we have a couple of design partners, heads of testing at some agency, customers who have fed into this, right? Because when you do the Figma versus the actual screen, the Figma, they need to be kept up to date. Only then it really works, right? And that's why you see a lot of the visual testing things not really being really useful because you do the visual testing, but you also have to do the whole thing all over again. What our customers have been telling us is that What we're not, what they're looking for is not an exact match of the screens in Figma, but whether the design system has been adhered to. Is the curvature correct? Is the color scheme correct? Are the colors being used correctly? Is the thickness of the lines correct? And that's really what we're going to test in our design.

Absolutely. And you also mentioned, you know, the BDD, uh, people sometimes get turned off by DD. Let's call it natural language. English language. So, uh, what I like about this, I used to work in regulatory environments, insurance, healthcare, um, and because the crawl is doing its thing, I think it's cool because then it's documented in natural language. You can hand to like an auditor and say, hey, here's what it did. And they could just read it and it's in plain English. Do you see that as a benefit as well?

No. Yeah, it's both, right? So there is plain English. You can actually go and see what goal the crawler set itself in every journey in plain English. Where the BDD helps is especially if you want to migrate or you, or you want to go from N to N+1 and you want a base which testing engineers want to understand and be held accountable to. That's when this helps. Natural language is tough to hold people accountable to, right? Because by its very nature, it's ambiguous. It really helps us also in migrations. When you want to migrate from a different platform, etc., if you have the BDD format available, it's very easy for a crawler to go in. And start creating test cases.

Oh, interesting. All right. So you have any real world case studies maybe that shows how this worked in the wild? Like, did it help? Like, what, how did it help? Like if I was trying to get some, a feel for like how it could help them.

Yeah. So I'll give you an example from one of our customers, right? So this is an automobile company has, uh, their mobile app is on both Android, iOS used on multiple devices. They have about, if I remember correctly, about 700 test cases, about 14,000 to 15,000 test steps. We've gone in, done the sanity testing autonomously and so on. What we also realized, and this is a key point, right? Our pitch is never that we're going to replace 100% of the test cases. About 80% of the test cases are automatable in that particular customer. But these 80%, the 10-15% which are The sanity cases we do autonomously. And as versions change, as production releases happen, we're able to test them over and over again correctly, right? And auto-heal and do them over and over again. Whereas the remaining 60-odd percent, which are the edge cases, the boundary conditions, the complex cases, etc., are— we use a record and play tool module to allow our customers to record. So it's a combination of the autonomous plus the record and play, which actually help you get to 80% automation. And the remaining 20%, as in a lot of cases, are not automatable. And that's fine.

Yeah, absolutely. You did mention auto-healing, self-healing. It's kind of a loaded term. When a test does heal itself, like how often does it heal incorrectly and pass when it should fail? Does that ever happen? Is that something they should be concerned about?

No, good question, right? And so again, we've— I've dealt with AI systems for a long time and I think false positives and false negatives, we take them really seriously. So the way we think about this is our best way to do matching is through element IDs. If element ID exists, great. If it doesn't exist, because we are capturing a bunch of information from the node, from the Every screen, we then try to do a fuzzy match with some of the metadata we have captured for that element because we have that in our graph. When that is missing, even that is not matching, that's when we go to image. And I'll show you an example. I'll share my screen and show you an example of how test healing happens, right? So this is AI-assisted, right? This is where on the booking platform app. We are doing AI healing. So what happens here is, so what's happened here is, and this is very common, right? You can see the screen here, the where to, the destination has to be entered. And that element ID is usually dynamic in a lot of apps and therefore the element ID will change. So what you've seen here is our product going in and one, checking whether the element ID exists. Now, a very common issue in mobile apps is the element might not yet be loaded when you're trying to do the test, right? So we do check multiple times if the element exists or not. So this is our product checking 5 times if this element has finally been loaded or not. If the element is not loaded, and finally, then we go to AI Relay. And within this particular case, what happens is during— we do the fuzzy matching, which I told you. If the fuzzy matching also fails, What we do is during the record time, we take a screenshot of the place where the click has happened and we match it to the execution screenshot. And in this case, where even though the element ID has changed, the fuzzy matching has changed and so on, this auto-healing is successful and we are able to go forward in this, in this test case, right? And you can see the test case is successful. We're able to add. And then go and finish our test case.

Technology. You're not called Mobile QA Pilot, you're called QA Pilot. Do you have any plans to, did you start with the harder thing to automate first and then you plan on building out from there to do web or is it just going to be a mobile platform?

Huh, so we've thought about this a lot, right? And our view is, our differentiation is in being deep in the mobile app ecosystem, right? And a fair point about the name of the product, but the way we think about it is we go into mobile apps and then we go across dev, SRE, QE, and then create that layer of quality across the organization. We believe that that's where the opportunity is going to be in today's world where the delivery timelines are getting Yeah. So the way we see this is, uh, engineering was fast from, uh, sped up from a waterfall to agile. But the way the agile system works is there's a stage handover between different teams, right? What that— what's happening with today's tools is that everything is kind of getting overlapped. Dev, in some cases, the dev team is the release team. Manages releases. In some places, the release manager is from the SRE team. All of this is changing. So in this situation, what are the tools which are really required is our, is what we are trying to build. And our approach to that is this. We want to be best in class for mobile apps, but have a view and integrate into different tools. The Dev IDE, we want to integrate into it. We, like I told you, we want to integrate into your observability tool and democratize access to a bunch of functionality. So we believe that 80% of the tasks, like for example, the example which Anand gave you from Reveal, right? A bunch of SRE tasks can be done with 20% of the functionality where you're looking at the main journeys and making sure nothing is going wrong. And we believe that we don't want to be best of breed SRE tool, not a best of breed IDE. but integrating into them and giving 20% functionality to the rest of the organization can make the whole organization much faster, more nimble, and also let the experts focus on the real 20%, which are the tough problems to solve in Dev or SRE. So that's how we see the future of our product.

So I guess my next question is, how does it? How does it, in the software development lifecycle, where does QA Pilot come in? Like, is it dev coding in their IDE and then they call your agent, run your scan? Like, when does QA Pilot, is it like when they check in code, it goes and runs as a confidence sanity check? Like, where does it fit into the pipeline?

So we integrate into CI/CD pipelines. So when the code is checked and is ready to then move to the next stage for before handover to the QA team is when you would run your test cases on QA Pilot autonomously. We also are used by the QA team to record, create more test cases and run them before they then hand over to the next team, right? And probably go to the release manager for review. So that's where QA Pilot is currently used by our customers.

So like, what's your go-to-market strategy? How do you compare to other people that are out in this field? Like what's your differentiator? How are you tackling this?

Yeah. So our primary go-to-market is through our partners and our partners tend to be quality engineering services companies and dev houses who are building mobile apps. They're the best kind of partners for us because they, the kind of customers we are talking about, right, have millions of users, have to make it work on a breadth of devices, mission-critical apps, and so on. They tend to outsource some of their testing to services companies. And these are the companies who we then provide automation services product. And some of them call it accelerators. And this is essentially an accelerator for them to get up to speed very quickly for their customers. So that's our go-to-market strategy. And we're building for that channel. The next thing is in terms of our differentiators and modes. We have, over the period of time, we've collected a whole bunch of data on mobile screens. So we are extremely good at identifying what's a home screen. We're extremely good when we make a change in our crawler logic, whether it's working or not, because we have a strong eval framework to check different types of journeys. And that really is a differentiator because we've collected data over a period of time, we've created this eval framework, which then allows us to confidently push changes to our agentic framework into production.

All right. So what about if someone's listening and they're like a hands-on mobile tester and like, and they work for a huge company like Amazon or I don't know, Fidelity, can they still try QA Pilot? Like how can you get, how can they get their hands on QA Pilot and try it for themselves?

So you can go to our website, request access. We'll do a quick call with you and then You can get access. There are some POCs we are doing where customers are using it directly, but our impression has been that most of the final usage happens through partners. So, so maybe to break it down, right? So the customer has to agree to use our tool. They do test our tool, use our tool. They make sure that they're happy with it. Then it's future-proof. They can see that they really works and so on. And then the partner comes in and then finishes the work for them and maintains their test cases and so on. All right.

Before we go, is there one piece of actual advice you can give to someone to help them with their mobile testing efforts? And once again, any other resources you think people should go to, to learn more about QA Pilot?

So we have a lot of information on our website. We have our docs, which is documentation, which is public. we don't really hide anything. Uh, you can go learn more about QApilot. We are also very happy to interact with people. You can write to me directly. Uh, we can probably link that in the show notes, uh, and so on. Right now, for what, what advice we would give to people who are getting into the mobile app testing, right, is to really look— this is our really our reason for being, right, is that mobile apps are fundamentally different, uh, and you need to have a a mobile app specific strategy to do your mobile app automation. And tools like UiPilot will help you along the way because we are mobile app specific and we really work very well with every type of mobile app framework which is out there, whether it's React Native, Flutter, or native Android and iOS.

Awesome. You can find links to all this awesomeness down below.