Mobile Testing for Recruiters: How to Actually Read a QA Job Description or CV

A friend of mine who works as a tech recruiter recently called me about a new mobile QA role.

She had encountered a familiar problem: the job description contained a mixture of mobile platforms, programming languages, application technologies and testing frameworks. It all seemed too confusing. And that is understandable: if you are not an engineer, it is often far from obvious which is which.

“Mobile testing experience” can describe quite different technical backgrounds, and a lot of questions can emerge:

What is the difference between Espresso and Appium?
If someone has tested Android applications, can they test iOS applications?
And if a company has a cross-platform app, does that mean it needs a cross-platform testing framework?

Here’s how to break it down so none of it is a guess.

This post is primarily for tech recruiters working with mobile QA roles, but it may also be useful for recruiters who are new to technical hiring, people starting out in QA, or anyone who regularly encounters mobile testing terminology without necessarily working with these technologies themselves.

Before ANYTHING else…

Before we go any further, there are three different things you will keep seeing in mobile QA job descriptions: platforms, programming languages, and testing tools.

A platform is where the app runs. For mobile apps, we are mainly talking about iOS and Android.

A programming language is what engineers use to write instructions for the computer. Examples you might encounter in mobile development and testing include Swift, Kotlin, Java and JavaScript.

A testing framework or tool helps engineers write and run automated tests. Examples include XCUITest, Espresso and Appium.

This distinction becomes useful when reading CVs because a candidate who does not have an exact keyword match may still have highly relevant experience.

Question to ask as a recruiter: Which technologies in this job description are platforms, which are programming languages, and which are testing tools or frameworks?

What kind of mobile app are we testing?

Imagine that a company wants to build an app for both iPhones and Android phones.

Option 1: Native apps

It can build two separate native apps: one specifically for iOS and one specifically for Android.

Think of it as:

This approach gives developers direct access to the features and conventions of each operating system. The trade-off is obvious: if you want to support both platforms, you are maintaining two codebases.

Option 2: Cross-platform and Hybrid apps

Another option is to use technologies such as Flutter or React Native to share much of the code between the two:

This is called cross-platform development. It trades away some of that direct platform-specific access in exchange for a shared codebase, although some platform-specific code may still be needed.

You may also hear the term hybrid app, usually referring to an application built primarily with web technologies such as HTML, CSS and JavaScript, which then runs inside a native mobile container. For now, the important thing is simply that “native,” “cross-platform,” and “hybrid” describe how the application itself is built.

They don’t automatically tell you how it is tested.

Question to ask as a recruiter: How is our app built: native, cross-platform or hybrid?

Testing ecosystems

Okay, we know now that an app can be either built exclusively for one platform (native app) or built for both platforms at the same time (cross-platform). These different development approaches have given rise to different testing ecosystems, although—as we’ll see—the relationship isn’t one-to-one.

Native testing frameworks

Native mobile platforms have their own testing ecosystems.

For iOS, a common combination is:

For Android:

These are common examples, rather than an exhaustive list of native mobile testing tools. For our purposes, the useful takeaway is that XCUITest points toward iOS experience, while Espresso points toward Android experience.

Platform	Common languages	Native UI testing framework
iOS	Swift, Objective-C	XCUITest
Android	Kotlin, Java	Espresso

Question to ask as a recruiter: Does this role specifically require native iOS or Android automation experience, or is experience with mobile UI automation more generally transferable?

As a recruiter, you don’t need to remember every single tool and every possible combination. But you should be able to recognize that if someone mentions XCUITest, they are probably talking about native iOS development and testing, for example.

Testing across platforms

So far, we have:

Easy enough. But mobile teams don’t have to use the platform’s native testing tools.

Mobile teams also have other automation tools available to them. Appium is one widely used example of a tool that can automate both Android and iOS applications. You may also encounter tools such as Maestro, while certain development ecosystems have their own alternatives — for example, Detox is particularly associated with React Native applications.

The specific tools matter less than the pattern: XCUITest and Espresso are not the only possible choices for mobile UI automation, and seeing “Android” or “iOS” in a job description does not tell you which automation tool the team uses.

And here is the important part: how the app was built and how the tests were built are two separate decisions.

The reverse is also true: a cross-platform automation tool such as Appium can be used to automate native applications.

Question to ask as a recruiter: Is this particular automation framework a hard requirement, or does the team primarily need someone with transferable mobile automation experience?

What exactly does “mobile testing” mean?

So far, we’ve been talking mostly about UI test automation. But that is only one part of mobile testing.

Someone might manually explore the application on physical phones and tablets. Someone else might write automated UI tests that simulate a user tapping buttons and entering text. Another engineer might focus on API testing, while another works on performance, accessibility, security or integration testing.

Even within automation, tests can operate at different levels.

A unit test might check whether one small piece of code behaves correctly. An integration test might verify that several components work together. A UI test might open the actual application and interact with it like a user.

Frameworks such as XCUITest and Espresso and tools such as Appium become particularly relevant when we talk about automating interactions with the application’s user interface.

That context matters when reading a CV. “Five years of mobile testing experience” does not necessarily mean “five years of mobile UI automation experience.”

Question to ask as a recruiter: What kind of mobile testing does this role actually require — manual testing, UI automation, API testing, performance testing, or a combination?

How to translate a mobile QA CV

Once you understand these layers, combinations of technologies become much easier to decode.

CV says	What it probably tells you
Swift + XCUITest	Native iOS automation experience
Kotlin + Espresso	Native Android automation experience
Java + Espresso	Android automation experience
Java + Appium	Mobile automation using Appium with Java
Python + Appium	Mobile automation using Appium with Python
JavaScript/TypeScript + Appium	Mobile automation using Appium with JavaScript/TypeScript
Flutter	How the application was built; does not by itself tell you how it was tested
React Native	Same: application technology, not automatically the test framework

This also explains why exact keyword matching can eliminate potentially relevant candidates.

How transferable that experience is depends on the role, which is precisely why understanding the categories is more useful than simply checking whether every technology from the job description appears on the CV.

Question to ask as a recruiter: Which requirements represent knowledge the candidate genuinely needs on day one, and which technologies could an experienced mobile QA engineer reasonably learn?

The four questions that make mobile QA job descriptions easier to read

As a recruiter, you’re not expected to memorize every detail of the mobile testing ecosystem. You just need enough context to place the technologies correctly.

There are four useful questions to answer:

• Which platforms are we testing? iOS, Android or both?
• How is the application built? Native iOS/Android, React Native, Flutter, hybrid or something else?
• What kind of testing does the engineer need to do? Manual testing, UI automation, API testing, performance testing or some combination?
• What automation stack does the team currently use? Which framework or tool, and which programming language?

From there you will know what the technologies represent, how they relate to one another, and — probably most importantly for recruitment — which questions to ask the engineering team before you start looking for candidates.

Appendix: Mobile Testing Ecosystem Map

A quick-reference table for the tools mentioned in this post — who they’re associated with, which platforms they cover, and what language you’d typically see them paired with on a CV.

Tool	Common association	Platforms	How tests are written
XCUITest	Native iOS	iOS	Swift (primarily)
Espresso	Native Android	Android	Kotlin / Java
Appium	General mobile UI automation	iOS + Android	Java, Python, JS/TS, C#, etc.
Maestro	Mobile UI automation	iOS + Android	YAML-based flows
Detox	React Native testing	iOS + Android	JavaScript / TypeScript

This table is illustrative, not an exhaustive list of every mobile testing tool.