Unveiling the Potential of XCUITest and Espresso with Igor Dorovskikh

[00:00:04] 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.

[00:00:25] Hey, it's Joe, and welcome to another episode of the Test Guild Automation Podcast. And today, we'll be talking with Igor, all about Mobile Testing, specifically about probably XCUI tests, Expresso, and all things Automation Awesomeness. If you don't know, Igor is an accomplished CEO and Founder of Engenious.io, a leading mobile consulting startup that caters to top-tier clients. He's worked with people like Apple and Grammarly. He has almost 15 years of experience in mobile development and he has accomplished author and authority in this field with a focus on building world-class engineering teams that deliver mobile app applications. I've met with him multiple times. We've met up at Selenium Conf, he has worked on a lot of cool things. He has some open-source projects that's been working on. He has some educational things he's working on that he'll be unveiling shortly. So a lot of experience. He also works at a lot of or used to work at a lot of top Silicon Valley companies, like I think he worked at Barnes and Noble, Expedia, and Tinder. He played a key role in driving mobile release management, mobile DevOps, and Quality Processes across multiple companies. And he's a guest speaker at multiple conferences as well. Really excited to have him on the show. You don't want to miss this episode. And also I'm really excited to let you know he's going to be doing a 90-minute workshop at the 2024 Automation Guild. And to check that out, head on over to Automationguild.com. It will be released soon and registration be open soon. So definitely check that out as well. You don't want to miss this episode. Check it out.

[00:01:57] This episode of the TestGuild Automation Podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to your brand awareness, lead generation, and thought leadership goals to get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us from boosted event attendance to impressive ROI. Visit our website and let's talk about how Test Guild could take your brand to the next level. Head on over to TestGuild.info and let's talk.

[00:02:32] Joe Colantonio Hey, Igor. Welcome to the Guild.

[00:02:35] Igor Dorovskikh Thank you, Joe. Thank you. I'm thrilled.

[00:02:38] Joe Colantonio Awesome to have you. It's been a while. I've been wanting to have you on the show for a while and I don't know why it took me nine years. But welcome. Excited to have you. Before we get into it, is there anything I missed in your bio that you want The Guild to know more about?

[00:02:50] Igor Dorovskikh Oh. It was an amazing bio. Probably one of the best intros. Thank you, Joe, I think it said it all. I've been in the Testing Community for a long time, test automation was a big thing before and a lot of people thought about this. I talk about this in mainstream and even up today, they're running the company, which is a mobile-first company, not just test automation testing but also mobile development. I'm a huge evangelist and a big fan of yours, and I am still in the industry of testing and test automation.

[00:03:21] Joe Colantonio Love it. You have a really interesting background, just curious to know how you got into mobile testing because you've been there for a while and you're one of the first people that actually I know that really started innovating in the area. So how did you get into mobile automation testing is one of your real specialties?

[00:03:37] Igor Dorovskikh Yeah. Thank you, Joe, for this question. I think that it just happened naturally. My first internship was mobile before iPhone and Android era on, if you remember, Symbian J2ME platform back in 2006 and 2007. I got into the mobile before what people actually talk about mobile. And back then we even automated on those platforms. I work on a startup that was building the SDK for Eclipse to build the applications for J2ME forms and Symbian forms. We were writing automation even before people talked about automation. And naturally, I segwayed into Android first because Android was more mature than iOS, if you remember 2008 and 2009, those break J1 phones. I started automating with Robotium back in 2008 2009 because instrumentation actually 2009, 2010 because the instrumentation that shipped was the original SDK wasn't usable as a framework for automation, so Robotium was the thing. And then, around 2012, I slowly moved to the iOS automation. There was a framework that used to be called Frankenstein, Frank. And then I met Jonathan Lipps at the conference in GTAC 2013 and he convinced me to use the prerelease version of Appium from 2013 until 2016, I was a huge SauceLabs evangelist walking through different conferences internally and externally, like Facebook, you name it, like Visa and talk about Appium and how great it is. And around 2015, after the Espresso framework was released, I started preaching about Espresso. Valerie did a great presentation in 2013, but the still wasn't open to the public. But in 2015 I started converting back to the days when I worked at Expedia, and I started converting from Appium to Espresso. And then the 2016 and 2017 XCUI Tests. I lived through the entire transformation in the mobile space of test automation. Quite a journey.

[00:05:47] Joe Colantonio Yeah. Loved your background. Why leave Appium? Any pros and cons of when someone should use it before we dive into some other solutions that may be a better fit for certain companies?

[00:05:58] Igor Dorovskikh It's a great question because a lot of people ask this, not only people customer ask of this question, when should we use one over another? And the answer is it depends on the problem they try to solve. As of today. It's crystal clear, if it is negative, if the application builds natively, like using the iOS stack or Android stack, definitely use a native solution. That's the way to go. I spoke with a lot of folks got their feedback. Appium was really flaky to go Native. Probably 80% of the best shot. However, if the app is built as a cross-platform using frameworks such as React Native, then I think Appium is indispensable. So I would personally use Appium for cross-platform applications.

[00:06:44] Joe Colantonio Absolutely. Normally, on the podcast and when I go to conferences, you always hear about Selenium and Appium. Not so much by XCUI Tests, maybe sometimes, but even less about Espresso. Why do you think that is? Or do you think is there a big community around Espresso is just something that's so niche that maybe that's why you don't hear about as much as Selenium or Appium?

[00:07:06] Igor Dorovskikh I think that's a very good question. Here I think there are several reasons for that. So number one is the verticals. It just happens to be that from the Selenium era, right? When Selenium became popular in 2011, 2012 was the Selenium Web driver 2.0. A lot of manual testers started converting to test automation this or that. And that segwayed into the Appium. So a lot of management and that's the thing that I'm going to focus on management made a decision to build horizontal expertise in test automation for the teams where they take a test automation engineer or SDET and say, okay, now you the web, mobile, iOS, Android, or back-end, you name it versus the XCUI Test Espresso, this is verticals. So similarly for development. Have you ever seen a developer that works on iOS development that does Android? Probably not. Similar and vice versa for the iOS. I think that there are on topics that are not spoken about at the conferences and widespread is because of expertise in one area. In my perception, because I've been teaching that topic also for a long time in our boot camps, in our programs, over the course of right now 10 years, I've noticed that the best SDETs for the iOS or Android are those or come from a development background. So in my experience the best conversion of would take like fairly technical person like a junior iOS developer, you can convert from quickly. From the QA, you have to learn the platform itself. But however, the power of XCUI Test Espresso is way more in terms of the impact than using the cross-platform solution. It's about expertise and domain knowledge I think that's the key. And management usually makes a decision to create like a cookie-cutter approach. Okay, let's just build the universal soldier who will do everything instead of building the verticals. I think that's the main reason.

[00:09:12] Joe Colantonio When someone is in a vertical who tends to do the testing then? Is it mostly developers that are using XCUI Test Espresso or like you said, because you do need some programming language? Does testers can evolve later on? How does that normally work?

[00:09:27] Igor Dorovskikh Normally, if the management makes their own decision and put a dedicated person and wasn't a reasonable goal, say okay, for next year, you didn't do anything else. But let's say, iOS automation, nothing else. So you have to focus on one platform, we're not going to touch you. So that person becomes knowledgeable in that platform. They work with development. Don't forget that all the source code for tests when you automate an XCUI Test or Espresso listen in the same code repository as the application under test, which means that they will naturally work on the same environment the PRs will be popped out for developers as well on that platform. they talk the same language. Usually, the person develops with the team an amazing side effect that I noticed is it's amazing one, folks who work as the SDET on either iOS or Android vertical automating those native solutions about after one year get converted to developers but they have the main knowledge and they sustain the framework, not only the test but infrastructure because besides testing, you will have to work with the TestOps infrastructure for that native thing. That's how usually people build up. You could be a very solid test automation engineer coming from the web or back-end, it doesn't matter, but they have to stay focused on one platform for a long time. So not necessarily developers, but I've seen teams where developers get tasked to support those tests, but that's very subjective because, I mean, developers have to spend a lot of time to build features and fixing bugs. And that's why the SDET role exists, right? And then we recommend that companies don't mix those roles. But I've seen companies that successfully implement this, and it's doable. But that's the reality of today's world of software development in the mobile space.

[00:11:19] Joe Colantonio So, Igor, I think that's got to just set the stage before we dive a little more deeper. I just assume everyone knows about XCUI Tests and Espresso is, but I'm not sure. Let's just define what is XCUI Test and what is Espresso before we dive in anymore.

[00:11:33] Igor Dorovskikh Yes, it's really simple, XCUI Test is the library that ships with the Xcode. So when you download Xcode for iOS Development, it's already part of it. You don't have to install anything else third party, it's just the additional library for writing UI functional tests on top of their XCUI Test libraries extension of XCUI Test library for unit testing. So you use it for writing functional tests for a variety of Apple products, not just the iPhone. You can write it for Apple Watch, you can write it for Apple TV. And we actually have clients for Mac OS as well. And in terms of setup, it takes we actually did measure that. It takes under one minute to set it up just a couple of clicks and then good to go. In terms of Espresso, similarly to the XCUI Test, it's the library that ships with the Android SDK. And so when you download Android Studio out of the box, you need a couple of things was the Gradle all setup and Gradle is, for those folks who don't know what Gradle is just a wrapper on top of the Maven for Android. And it takes literally like a minute also to set up the Espresso test. Espresso is just the library, they have also UI Automator. So it's not only one testing library. The ships was the Android SDK and those frameworks they use for native automation of Native iOS and Android applications are extremely powerful. It can do a lot of things like that Appium cannot do physically because Appium mostly is a black box automation. So you can like write your own interceptors, you can launch isolated activities like a screen, you can put the applications certain state, you can test client analytics, and you can control A/B tests from the inside app, which is why it's so powerful. Those are frameworks. In a nutshell, that's what they do.

[00:13:31] Joe Colantonio Nice. So they tend to test, do they tend to run faster? It sounds like you set them up quicker than maybe someone started with Appium but how about speed-wise of this test because they're native, do they run quicker or any other benefits?

[00:13:42] Igor Dorovskikh Absolutely. And that's why I recommend we go native, try to use native frameworks for exactly the reasons we mentioned. Speed is the big thing. I mean, when you have like 10 or 20 tests, it doesn't matter. But when you have thousands, it becomes really matters, especially when your management tries to run it, every PR merge. So every like commit. So we want to trigger all these tests so you cannot run them for hours. The biggest benefit there fast and I mean when people talk about Appium, Appium 2.0. Today's Appium is a wrapper around those frameworks. So under the hood, there are still those Espresso and XCUI Tests. The Appium was just the wrapper around those native frameworks and you still kind of use them under hood. But don't forget about Appium architecture. It's a Node.js server. It creates an extra layer of complexity and also creates an extra layer for flakiness. So basically you remove that extra layer using native. So yes, speed is going to be a big difference. Another thing is orchestration and stability because you have full control over the application under test and like I mentioned, it's more like you can do more white boxes things, you can do like things that you cannot do with Appium. And I just mentioned those examples like for instance, Deep Link or put applications in state or mocking. You do not have to write a separate server for that. You can mock them right on the spot. Just a few examples where it's so powerful. And a great example, a lot of clients are asking to compare Appium because they're already using Google's Native solutions. So I mean, I'm just saying these numbers not because I just want to show off or just bring this is a real numbers. You can, if you're doing the right thing, if you write a task was a good architecture in mind and using the best practices was XCUI Test Espresso you can achieve 98% stability. It's very high. Why not 100%? It's because there are infrastructural things that cannot be controlled. And then becomes the more TestOps, DevOps. But from the task perspective, you can achieve 98% fairly easily with native solutions.

[00:15:57] Joe Colantonio Pretty bold statement. So is this from experience or is this like something just you've seen over your career when you work for clients like go and get Appium versus I'm not saying one is better than the other, but just say in general, why are they more stable, though? Is it because people don't know how to write correct Appium test or just because it is native that it's in the ecosystem so it just tends just to run smoother and more reliably?

[00:16:21] Igor Dorovskikh Both. I mean, I understand it's very bold statement, but again, I speak from my experience. I teach this thing, I talk to a lot of students. I talk to a lot of people from various companies. As a matter of fact, I just came back from task where we did the workshop and folks are asked folks with Appium was their stability and the same or roughly around 80%. So the 20% flakiness that's the reality. I mean, but in native automation, how we can achieve this? Absolutely. And don't forget that you are working on the same toolset as the developers. You are very close to that. A lot of apps are not automatable. You have to make the app automatable because you work on the same stack with them, you can do that, you communicate the same language with them. That's one reason. So you can influence the app to be more stable and be ready for automation and add necessarily hooks like accessibility identifiers. So content descriptors. And you can do that. You can do it on your own. Not to mention this. There will be automation to reveal the bugs that manual testing cannot reveal. And again, you speak with developers. That's one way. Second is because it's native, as I mentioned, Appium creates extra complexity because it's a server run is a wrapper around this. So you remove all this noise so you can use parallel test execution much faster than use like Selenium Grid. It was Appium-like architecture which basically cannot be very fast by its nature. Again, I'm not just saying that Appium was a bad tool, no, Appium was an amazing tool, but for the right reason. If you ask me today, Igor, what would you choose for cross-platform testing? I would go myself and do Appium, it was just better. But natively, to achieve that 98% stability, you have to use best engineering practices and follow those protocols. It's not like you're going to by default if you write XCUI Test Espresso Test you're going to get 98% stability, no, you have to follow best practices. Like one of the great examples is network mocking or call stubbing. Without those things, you will never achieve that stability because back-end by itself can undergo multiple deployments per day, back-end can have hundreds of A/B test experiments. How you're going to control end-to-end test? By writing a test that are hitting the back-end, even XCUI Test Espresso I'm going to give it this 98%. However, orchestration is going to be a very important thing.

[00:18:44] Joe Colantonio Igor, you mentioned network mocking a few times. Maybe can you give us a little heads up on best practices or ways you maybe see where people don't leverage network mocking and how they can and what it really help them with?

[00:18:56] Igor Dorovskikh Yeah. I mean, usually, when we're talking about network mocking. The whole terminology came from development, that's why when developers write the unit test, they have to mock everything. And that's what actually gives the unit test so much stability. But when we come to the test automation for functional test automation. And when it comes to the test automation engineers and they hear this phrase network mocking or stubbing, it just gives them goose skin like OMG! What the hell it is? What should I do with that? I think that comes with the background of most test automation engineers because they're not coming from a development background. They come from the testing background. I think they just spook them off. But network mocking out of the box for Android. It ships was the mock HTTP web server, which you can do as just another library. Basically, what you do you record server responses and you alter them. You don't need to have gigantic responses from the back end and store them locally. And when the app actually hits that request, that redirects them to this fake data. This way you always have the same outcome. Let's say that if I use an application like the Chat App. I always challenge with Joe, not anybody else. And I always get Hello World, so I know exactly what the application is going to return, which is actually brings another question what about the end-to-end test? And that's where manual testers are supposed to be, right? So we are testing the Android or iOS app in isolation or like Hermetic testing. Back-end should be tested by the back-end test like API or microservices. And that's how we know that those tests are actually finding the front-end bugs, not the back-end bugs. So mocking is very essential for testability and speed because we completely removing that round trip from the request-response. And a lot of people ask me like, what about web sockets can we mock them? Yeah. What about protocol buffers? Absolutely. It doesn't matter. We can mock everything. But there are different tools available. There's a third-party solution like SBTUI test tunnel that has been used for a long time. So what we did in Engenious, we built our own solution like a VCR recorder. If you remember those from the days which is basically a proxy that allowed all the requests to come through. But next time it redirects to the fake data. So we created this very easy, very lightweight mock web server, which helps to eliminate the fear from these test automation engineers and help them to ramp up to the SDETs pretty quickly. Instead of sitting and trying to understand how the backend works, what the response schema is supposed to look like and use the Charles for that.

[00:21:49] Joe Colantonio What's the name of that tool?

[00:21:52] Igor Dorovskikh We're not open source.

[00:21:54] Joe Colantonio Okay.

[00:21:55] Igor Dorovskikh We just use it for internal clients.

[00:21:58] Joe Colantonio Gotcha. Gotcha.

[00:21:59] Igor Dorovskikh But we're planning to do something about this when I'm sure we have it internally. So far, we use it mostly for our students and for our clients, but we haven't open-sourced it yet. However, I will give you the links of the open frameworks that are available and we can share with the community down on the video there's a link. Yes.

[00:22:21] Joe Colantonio Absolutely. I'll have that in the show notes for sure. People should definitely check out. So besides network mocking, you mentioned orchestration. I assume the orchestration would be easy with Appium, but is orchestration different when you use XCUI Test or Espresso? And if so, like what do you use to make it more seamless or easy?

[00:22:41] Igor Dorovskikh Can you elaborate on the orchestration? Because orchestration, it's a very broad term, right?

[00:22:46] Joe Colantonio Just running tests in parallel or across multiple devices really quickly, I would say.

[00:22:52] Igor Dorovskikh Okay, because there are a lot of people mean different things when I talk about orchestration. In terms of the test execution, absolutely. So we built our self open source solution for that because back in 2019 when we started getting our first clients for consultancy, we couldn't find one. We tried to use BluePill, we tried to use a few others, but nothing worked out of the box. We built called Sift. I'm going to provide a link. It's on the GitHub, it's open source, completely free. So Sift built for both iOS and Android and it helps to run tests in parallel natively. And it's very configurable. It has the rerun mechanism on it. You can add nodes as many as you need and you can build even auto scaler. So basically the more tasks you have, you just add more nodes and it's going to run in parallel and it's super fast and very stable. We use for existing clients. That's how we continuously update it. We got a few community members who started using that as well and we're on the Discord community. Our people come to join us and ask questions and we'll help them with the setup of the Sift, yes, but there is like when we talk about enterprise. So when we have like for instance, one of our clients is Apple and then you have thousands of tests, right? So for that reason, there's a very different DevOps and TestOps involved. Lately, we partnered up with the company called Marathon Labs. There are a lot of companies Lambda test, Browserstacks, SauceLabs. I mean, I'm not going to have spin. You probably had all of them on your show.

[00:24:31] Joe Colantonio Absolutely.

[00:24:32] Igor Dorovskikh But you never had a Marathon Lab?

[00:24:33] Joe Colantonio No.

[00:24:34] Igor Dorovskikh Who are these guys? I completely randomly met them. Oh, you probably heard about Keys.io Nikita, I think. You had him on the show. He introduced me to these folks. This is just a bunch of very smart engineers who tried to solve the problem of enterprise-level test execution for Native Test for iOs and Android so they don't do web, they do only Native. And their one-liner kind of advertising is no matter how many tests you have run in them under 15 minutes. I was like, no way. I tried them, I POCd them, and they do it. They're a very crazy DevOps setup, they actually run thousands of tests in under 15 minutes, one five, not 50, 15. We partnered up with them and they are doing a great job. One of the co-founders of them, I think Kaspresso is a wrapper around Espresso. There as well very smart guys like so and again, the broad expertise natively they think they've built Android first and iOS next. And when we need to go for enterprise setup like test orchestration we use them. If it's a start on it's overkill. You don't need to use them. So we use the Sift and just set up the local environment. I mean, local doesn't mean like a physical Mac Instance we're talking about like some cloud like AWS, for instance.

[00:26:01] Joe Colantonio But I actually saw a demo at Selenium Conf that gave me a quick overview seems really cool. It supports real devices as well, I believe, and has a reporting system, has all these cool things built in for free.

[00:26:13] Igor Dorovskikh Are you talking about Marathon labs or are you talking about ...?

[00:26:15] Joe Colantonio No, Sift.

[00:26:16] Igor Dorovskikh Oh yeah. We support everything. Yeah. Sift. Yeah. We actually presented TestCon in Vilnius recently. We have supported this for right now 4 years. And it's very scalable. I mean there are no boundaries there. It supports, by the way, also Mac Os to iPhones, support physical devices, and emulators and you can scan vertically and horizontally. No limits. Yes.

[00:26:41] Joe Colantonio I guess another maybe stumbling block for some people who are testers testing focus. Are there any resources available maybe to beginners to learn XCUI Tests or Espresso? And how steep is maybe the learning curve compared to, say, Selenium or Appium?

[00:26:55] Igor Dorovskikh I wouldn't say it's more steeper. I think it's more or you have to be more focused. What I recommend people who decide to go to their road. I mean you have to have some sort of a plan. You cannot just go like with all the plan. And the plan has to be falls. Do you want to become an eventually iOS or Android Developer? If this is the plan, if you're thinking that in the near future, two years from today, one year, three years, it doesn't matter. You want to become iOS or Android Dev that's number thing you have to ask yourself because what happens? Again, I just noticed this over the course of the past five years all SDETs that we're trying to convert or build they eventually become Devs. This is the reality. If you want to go that road then yes absolutely. In terms of a learning curve, you will probably have to dive deeper in iOS and Android development which is not hard nowadays. I mean, Kotlin and Swift are very easy languages to learn, not harder than Python. They actually use some Python elements in them and JavaScript. It's very, it's not Objective-C and Java which used to be if you remember, Joe nightmare right to learn back in the day. But the Swift and Kotlin are fairly simple. So the learning curve is not steeper than you do for web like using Playwright. But what you will encounter is learning and the main knowledge of the platform. That's going to be the key. That's what their whole time. So you're going to learn how to automate tests pretty quickly, but it's going to take you probably close to one year to get familiar with the platform. And again, every app is unique. There is no like all apps are the same. I bring up a different architecture and use different libraries. Also, every team has its own culture. You basically live in that culture. You're going to talk to iOS developers every day or Android developers. Coming back to our original question, what are the learning resources? So not that many, to be honest. I mean there are a lot of for the beginners just to jumpstart yourself. Like I know that test automation university by Applitools and they have intro courses, they're a little bit outdated but they're good enough to jumpstart. Also, both Apple and Android have like recently, by the way, Google released a very nice course for Espresso completely free. Besides that, if you ask about like external resources I like Coding with Mitch you probably heard about this guy Coding with Mitch, he's a big evangelist on Android development. He has two comprehensive courses on Android test automation with Espresso. That's another big one. However, there's not much like enterprise level for the XCUI Test. So that's why we started our university in Engenious University in 2023, and we built a comprehensive-we spent more than a year and 6 engineers working on the course for this enterprise level set up XCUI Test. So we have them available right now on our educational platform. And next year we'll try to do the same thing with Android Espresso. But to be honest, for beginners, there are few resources. But the goal like in Devs, like enterprise-level setup like mocking or test architecture because iOS development page object model not going to work. It's not standard architecture do for web because Swift is protocol-based programming, not object-oriented. So there is a different approach, different architecture. So similarly to like Android is Robot framework. Not the robot as a testing framework, but the Robot Pattern. It's all doable. In my experience, it takes on average like 6 months to get from 0 to a person who comes from the right test and then about a year of experience on top of this. But again, what is your ultimate goal? You have to ask yourself.

[00:30:50] Joe Colantonio Absolutely. So I have to ask you this, just getting your perspective on where we're going with mobile testing specifically in XCUI Test and Espresso. As you know, AI is the buzz. Every solution I speak with nowadays for the web, they have the codeless solutions automatically will write the code for you. Similar to CodePilot. Does this help you learn XCUI Test and Espresso better because it can write the code for you? Do you see solutions coming out for mobile testing that leverage AI that you probably see maybe if someone was to dive into XCUI Test and Espresso they're going to be out of a Java out of date or like not, it's going to be easier to get into because you'll be able to leverage something like AI Machine Learning.

[00:31:32] Igor Dorovskikh Yeah, it's very modern question. I would say an up to date not so obvious and not so straightforward for the web. I think AI found itself very well at the moment we're talking about right now that you can generate a baseline test for the web much quicker using AI with ChatGPT for instance, Generative AI. But you see that how I envision today's like version of AI, it's mostly like your smart body that you talk to. We probably heard that many times. You still digest that information and make a rational decision that objectively it's right or wrong. If you don't have the domain knowledge, how are you going to make the decision? How to know what it actually gave to you? But the direct answer to your question is it's for the native apps. Definitely not so easy as for the web. We tried it. However, you can ask questions to build the example. So for instance, you trying to battle the problem and you need Google answers. So if you ask ChatGPT, it will give you a couple of examples that can put you on the right track for the solution. In that way, yes, but not going to write those tests. However, where I see AI will be I mean, AI is just artificial intelligence machine learning will going to go get us to is more like what Applitools does for the UI testing, not functional, not flow, but UI Visual testing because now, I think we can educate systems what is right or wrong, feed the data. And what you need to do this image like Applitols does like base screen on top of the new screen thing. Those types of things are going to be gone like sooner than we think. And I think that's what Applitools going to deliver. I sense it. I don't know. I'm just sensing that that's what they're going to deliver next Functionized, Applitools, Bert, I mean all these similar like competitors. I think that will be a huge breakthrough in the UI validation. But functional automation-wise, going through the flows, I still will be there for the foreseeable future, maybe 2 or 3 years then I don't know. But yeah, I recommend people and whom I recommend people to learn these native solutions is that if you want to become experts in that platform, become really good at this one of a kind, it's niche. But think about this, here's my iPhone. That's what you probably use everyday for everything. So think about it. That's one always like you want to be an expert in this and you will be desired as an expert in the industry and a logical step you will become a developer. I mean, it's very subjective maybe answer but the best I could.

[00:34:26] Joe Colantonio Awesome. Okay, Igor, before we go, is there one piece of actual advice you can give to someone to help them with their mobile automation testing efforts? And what's the best way to find or contact you?

[00:34:36] Igor Dorovskikh Yeah, my piece of advice again, comes from experience. Please don't jump from one chair to another. Stay focused. Right now, even more than ever before, there's so much noise. People talk about AI and you hear Joe on your talk show like you can get scared pretty quickly. You can get confused and paranoid. Just stay focused and pick up one like domain, like pick one vertical and become really good at this, at least for one year, don't change your mindset and you can actually make a use case for your management. Say listen, I want to be good and I will bring a huge benefit to this. So stay focused and become good at one thing, regardless. That's my piece of advice. And how you can contact me? LinkedIn, I'm there. And also, we run a Discord community and complimentary, completely free. I brought in more than 2 dozen right now experts in Native Test Automation and Test Automation Management to help folks because right now, like I said, we try to help the community. And I'm going to share the link with you. Joe can share with the community and then come with the questions any time and we're going to get you, your answers regardless. And we put on different verticals, web, native, back-end, and development. So you can find your niche there. I think that's the best way to talk to me at any time.

[00:36:03] Joe Colantonio Awesome. And a quick plug if you want to get up to speed on XCUI Test and Espresso, you definitely want to check out Igor's 90-minute workshop. That's part of the Automation Guild that's going on from February 5th to the 9th, and you can definitely check that out by registering at Automationguild.com.

[00:36:18] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/a474. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:36:56] 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.