DEV Community: Harini Mukesh

Worth a read...

Harini Mukesh — Thu, 06 Aug 2026 10:39:27 +0000

Surendranath Reddy Jillella for QApilot

Aug 6

The End of the Testing Pyramid: What Replaces It in the AI Era

#ai #testautomation #devops #testmesh

4 min read

Handling Dynamic Locators in Flutter and React Native: From Fragile XPaths to Intent-Based Testing

Harini Mukesh — Tue, 04 Aug 2026 11:35:01 +0000

Picture the moment: your regression suite is green, the sprint demo went well, and someone bumps a dependency version before the next release. Nothing about the feature changes. Nothing about your test code changes. Yet the next CI run comes back with forty failed tests, and every stack trace ends the same way: element not found.

If you've automated a Flutter or React Native app with a standard Appium or Selenium setup, you've lived this. It's one of the more demoralizing patterns in mobile QA, because the failure has nothing to do with a real bug. Your XPath simply stopped pointing at anything real.

Cross-platform frameworks earned their popularity for good reasons. Write once, ship to iOS and Android, iterate fast. But that same flexibility quietly broke the assumptions traditional locator strategies were built on. Most of us learned automation on DOM-based web apps, where elements carry stable IDs, classes, and a tree structure a selector can rely on. Flutter and React Native don't offer that same contract, and pretending they do is how test suites end up more fragile than the apps they're supposed to protect.

This post walks through why that happens at a technical level, gives you a fallback pattern you can drop into an existing Appium suite this week, and then looks at where the industry is actually headed with visual and intent-based testing. I'll close with an honest opinion on how much of that second half is genuinely useful versus how much is marketing dressed up as innovation, because in this corner of QA tooling, there's a lot of both.

Why Cross-Platform Locators Break in the First Place

Flutter Draws Its Own UI, Which Means Nothing Native to Grab Onto

Flutter doesn't use platform UI controls the way a traditional Android or iOS app does. There's no android.widget.Button or native UIView sitting underneath your checkout button. Flutter renders every pixel itself onto an internal graphics canvas, using Skia or, on newer engine versions, Impeller. As far as the operating system's accessibility APIs are concerned, a Flutter screen is one continuous picture.

Flutter does expose a semantics tree that accessibility services and testing frameworks can read, but it only gets populated where you explicitly opt in. Wrap a widget in Semantics or give it a Key, and it becomes an addressable node. Skip that step, which is easy to do on a fast-moving feature branch, and the automation layer sees a flat, mostly opaque tree with no distinguishing marks.

// BAD: standard Flutter widget with no accessibility metadata
Widget build(BuildContext context) {
  return GestureDetector(
    onTap: _handleCheckout,
    child: Container(
      child: Text('Checkout'),
    ),
  );
}

When Appium's UiAutomator2 or XCUITest driver inspects that screen, it finds generic bounds with no accessibility ID worth using. So engineers reach for the only thing left: positional XPaths that describe where the element happens to sit in the render tree right now.

//android.widget.FrameLayout[1]/android.widget.LinearLayout[1]/android.widget.FrameLayout[1]/android.view.View[1]/android.view.View[2]

That selector is accurate for exactly as long as the layout stays frozen. Adjust one padding value, add a banner above the fold, or update the Flutter engine version, and the index shifts. The XPath still runs. It just clicks the wrong thing, or nothing at all.

React Native's Bridge Loses testIDs Between Platforms

React Native has a different version of the same core problem. It bridges JavaScript component logic to native views, and that bridge behaves differently depending on your build pipeline, whether release minification is on, and how deep your prop drilling goes. A testID that works perfectly in a debug build can quietly fail to reach the native view once release optimizations strip it out, often on only one platform.

// Might work on iOS via accessibilityLabel, but silently fail on Android if it's not mapped
<TouchableOpacity testID="submit_button" accessibilityLabel="submit_button">
  <Text>Submit</Text>
</TouchableOpacity>

This is a genuinely nasty class of bug to chase, because your test passes on the iOS simulator and fails on the Android emulator in CI with no obvious cause. You end up debugging the test framework and the build pipeline instead of the actual feature, which is exactly backwards from what a test suite is supposed to buy you.

Strategy 1: Harden What You Already Have (Appium and Python)

If ripping out an existing Appium pipeline isn't realistic right now, the first real fix is to stop treating XPath as your default. Reach for framework-native accessibility identifiers wherever they exist, and wrap element lookups in a fallback chain instead of betting everything on one strategy.

Here's a pattern I've used in production suites. It tries the clean accessibility ID first, then falls back to platform-specific text matching before giving up:

from appium.webdriver.common.appiumby import AppiumBy
from selenium.common.exceptions import NoSuchElementException, TimeoutException
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC


class ResilientDriver:
    def __init__(self, driver, timeout=10):
        self.driver = driver
        self.timeout = timeout

    def find_element_with_fallback(self, accessibility_id, fallback_text):
        """
        Attempts to locate an element by native accessibility ID.
        Falls back to semantic text matching if the native ID fails.
        """
        # Strategy 1: try the native accessibility ID first (fastest, cleanest)
        try:
            return WebDriverWait(self.driver, 3).until(
                EC.presence_of_element_located(
                    (AppiumBy.ACCESSIBILITY_ID, accessibility_id)
                )
            )
        except (NoSuchElementException, TimeoutException):
            print(f"[WARN] Accessibility ID '{accessibility_id}' failed. Attempting fallback...")

        # Strategy 2: fall back to UiAutomator2 / XCUITest text predicates
        try:
            # Android UiAutomator text matching
            android_predicate = f'new UiSelector().text("{fallback_text}")'
            return self.driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, android_predicate)
        except NoSuchElementException:
            pass

        try:
            # iOS predicate string matching
            ios_predicate = f'label == "{fallback_text}" AND visible == 1'
            return self.driver.find_element(AppiumBy.IOS_PREDICATE, ios_predicate)
        except NoSuchElementException:
            raise NoSuchElementException(
                f"Element with ID '{accessibility_id}' or text '{fallback_text}' could not be located."
            )


# Usage in your test suite:
# res_driver = ResilientDriver(driver)
# checkout_btn = res_driver.find_element_with_fallback("btn_checkout", "Checkout")
# checkout_btn.click()

There's nothing exotic about this. What it buys you is a second and third chance to find an element before the whole test collapses, which turns a hard failure into a warning log line most of the time.

Where This Approach Still Falls Short

Be honest with yourself about the limits here. A fallback chain reduces false failures, but you're still playing catch-up with the frontend team. A designer renames a label, a developer restructures a component tree during a refactor, and someone in QA has to notice, then update the wrapper logic by hand. It's a real improvement over raw XPath, but it's still reactive maintenance that needs a human in the loop every time the UI shifts.

Frameworks purpose-built for these stacks, like Detox, Maestro, and Patrol, help by giving you first-class hooks into the app instead of treating it as a black box, and they meaningfully reduce flakiness. But they still lean on some form of stable identifier under the hood, whether that's a testID, an accessibility label, or a view tag. If your app doesn't consistently expose those, you inherit the same fragility no matter which framework sits on top.

Where the Industry Is Actually Headed: Intent-Based Testing

That gap, the fact that structural locators only work as well as your team's discipline about tagging elements, is what's pushing a newer category of testing tools toward a fundamentally different approach. Instead of asking developers to annotate every widget or asking QA to maintain ever-growing fallback wrappers, these tools try to identify elements the way a human tester actually does: by looking at the screen.

The difference shows up in how you phrase what the test should do. A traditional locator says something like:

"Find the element at //FrameLayout[1]/View[3] and click it."

An intent-based approach says something closer to:

"Perform the checkout action on the current screen."

Two very different pipelines follow from that:

Traditional locators: a hardcoded XPath or ID, a lookup against the current tree, and a hard failure the moment that tree shifts.
Intent-based testing: read the current screen state, run it through a visual and contextual model, and execute the intent regardless of what the underlying tree looks like.

The appeal is obvious if locator maintenance has ever eaten a sprint for you. If an engine can recognize that a button labeled "Pay Now" sitting next to an order summary is the primary call to action, it stops mattering whether that button is a native widget, a hand-drawn Flutter canvas shape, or a React Native component whose testID got stripped in a release build. It just needs to look and read like a checkout button.

This is still a young corner of the QA tooling market, and it's worth naming a couple of approaches rather than treating it as one idea. Tools like Mabl and Testim apply machine learning primarily to web apps and are gradually extending into mobile. Others are mobile-native from the start. QApilot is one I've spent time with in that second group, and it's a reasonable case study for how these engines tend to work: it pairs computer vision with contextual understanding to interpret a screen rather than parse a rigid accessibility tree, which is exactly the layer Flutter and React Native make unreliable. Broadly, engines in this category try to do three things well:

Read visual layout and text together. Recognizing that a button labeled "Pay Now" near an order summary is a primary CTA, not just an arbitrary tappable region.
Track state across the screen graph. Mapping how screens connect to each other so a test can auto-heal when a locator shifts between releases instead of failing outright.
Treat iOS and Android the same way. Working uniformly across both platforms without a pile of platform-specific conditionals scattered through every test.

None of this is magic, and I'd treat any vendor claiming otherwise with suspicion. Visual and AI-based element detection is still maturing as a category, and it can misfire on genuinely ambiguous layouts, dense forms, or apps with heavy custom theming where two elements look nearly identical to a model that's reasoning from pixels. If you're evaluating a tool like this, run it against your app's actual edge cases before you let it anywhere near a release gate, not just the happy-path screens in the vendor's demo.

A Sensible Testing Stack for a Cross-Platform App

Pulling this together, a layered approach tends to hold up better than betting everything on one tool or technique:

Unit and component tests. Keep flutter_test and Jest fast, developer-owned, and running on every pull request. These catch logic errors early and cheaply, long before UI automation is even relevant.
Core integration and API tests. Reserve lightweight assertion scripts for handshakes that genuinely matter for correctness and security, like payment and authentication flows, instead of routing everything through the UI layer for convenience.
UI and end-to-end exploration. This is the layer where locator fragility hurts the most, and where offloading regression coverage and edge-case discovery to an auto-healing, context-aware approach tends to pay for itself, whether that's a commercial platform or a fallback system you build in-house.

The underlying principle matters more than any specific tool choice: stop letting your UI suite live or die by a brittle element ID. Teams that decouple their end-to-end tests from exact locators consistently report real drops in maintenance overhead, and that time goes back into writing new coverage instead of endlessly patching broken XPaths.

My Honest Take

Locator fragility in Flutter and React Native is a real, well-documented engineering problem, not hype dressed up to sell a tool. The Python fallback pattern is genuinely useful and something you can drop into an existing Appium suite this week with very little rework, and you should see fewer false failures almost immediately.

Where I'd push back is on how neatly intent-based testing sometimes gets framed as the inevitable endgame. It's a promising direction with sound reasoning behind it, but it's still an emerging category, and results vary considerably between tools and app types. My honest advice is to treat this as a decision framework rather than a verdict. Keep unit and integration tests fast and boring, harden your existing locators with fallbacks in the meantime, and pilot an AI-based tool on a small, non-critical slice of your suite before you let it anywhere near your release gate. Compare it directly against your current pass rate and flake rate, and let the numbers make the call, not the pitch deck.

What's your experience been with cross-platform locator stability? I'd genuinely like to hear whether others here have built their own fallback layers, or tried a visual and AI-driven approach and found it held up, or didn't, under real CI conditions.

Checkout my new blog... lmk if you ever felt the same

Harini Mukesh — Mon, 27 Jul 2026 11:03:04 +0000

Harini Mukesh for QApilot

Jul 27

I Used to Hate App Updates. Then I Saw What Happens Behind the Screen

#testing #mobile #softwaredevelopment #qa

8 min read

I Used to Hate App Updates. Then I Saw What Happens Behind the Screen

Harini Mukesh — Mon, 27 Jul 2026 10:30:00 +0000

From "Ugh, Another Update?" to "Wait... There's So Much Behind This"

A few months ago, if my phone showed "Update Available" while I was in the middle of using an app, my first reaction was always the same.

"Seriously? Right now?"

Sometimes I'd postpone it. Other times I'd update it just because the notification wouldn't stop bothering me. Either way, I never thought much about it. As long as the app opened, did what I wanted, and didn't crash, I was happy.

Like most people, I only noticed an app when something went wrong.

If it was a free app and it kept crashing, I'd uninstall it and look for another alternative. There are plenty of apps that solve the same problem anyway.

But paid apps were different.

The moment I pay for a subscription, my expectations go up. During the free trial, I suddenly become a tester without realizing it. I click every button, explore every feature, and try to decide if it's worth my money. If something feels broken, I'm probably not renewing.

Looking back, I realized I only cared about the final experience. I never wondered how many people worked on the app, how many times it was tested, or how much effort went into making everything feel smooth.

That changed when I got the chance to explore a mobile testing platform.

Until then, I genuinely believed testing meant opening the app, clicking a few buttons, making sure nothing crashed, and calling it a day.

I couldn't have been more wrong.

The deeper I explored, the more I realized that every screen, every button, every animation, every permission popup, and every update notification has an incredible amount of planning and testing behind it.

It felt like discovering an invisible world that had always existed behind every app I use but one I had never noticed.

I Thought Testing Was Just Clicking Buttons... I Couldn't Have Been More Wrong

If someone had asked me what software testing meant before this experience, I would've probably said,

"Open the app, click a few buttons, make sure everything works, and you're done."

Turns out, that's probably the easiest part.

What surprised me most was that testing isn't about checking whether an app works when everything goes according to plan. It's about making sure it still works when things don't.

What happens if someone denies a permission request?

What if the internet disconnects during a payment?

What if the user rotates the phone halfway through filling a form?

What if a notification interrupts the app?

What if everything works perfectly on one device but breaks on another?

These aren't rare situations, they're everyday user behaviour. And someone has to think about every one of them before the app reaches us.

That's when I came across terms like functional testing, where every feature is verified to work as expected, and exploratory testing, where testers intentionally explore an app the way real users would, looking for unexpected issues instead of following a fixed script.

I also learned about cross-platform testing making sure the same app behaves consistently across Android, iOS, different screen sizes, and different OS versions. Something as simple as a button can behave differently depending on the device.

Then there are edge cases those unusual situations that don't happen often but can completely break the user experience if they're ignored.

The more I learned, the more I understood one thing.

Good testing is invisible.

When everything works perfectly, nobody thinks about the hundreds of scenarios that were tested beforehand. We simply assume the app is supposed to work that way.

One line stayed with me throughout this journey:

Testing isn't about proving that an app works. It's about trying to discover where it doesn't.

Because it's far better for a tester to find those problems than for thousands of users to discover them after launch.

One Bug Doesn't Mean One Person Fixes It

Another thing I completely misunderstood was what happens after a bug is found.

I always assumed the issue simply went back to "the developer."

A button isn't working?

The developer fixes it.

The app crashes?

The developer fixes it.

Simple.

But that's not how software teams work. Imagine a tester finds multiple issues on a single login screen. The button colour doesn't match the design. The spacing is inconsistent. The login API returns the wrong error message. The keyboard hides the login button on a particular Android device. To me, that looked like one screen with four bugs.

In reality, those issues belong to different teams.

The UI or UX team handles visual inconsistencies like colours, spacing, typography, and layouts. Mobile developers focus on how the screen behaves. Backend engineers investigate API responses and business logic. Sometimes Android and iOS teams even work separately because the same feature can behave differently across platforms.

That completely changed how I looked at testing.

I realized it isn't just about finding bugs, it's about communicating them clearly so the right people can fix the right problems.

One thing I found particularly interesting while exploring QApilot was how findings can be organized instead of being dumped into one long report. Visual issues can go to the design team, functional issues to developers, and backend-related findings to the engineers responsible for those services.

That might sound like a small detail, but when multiple teams are working on the same product, structured reporting saves a lot of time and confusion.

Before this experience, I thought testing ended once someone discovered a bug.

Now I think that's where collaboration really begins.

Behind every app we use are designers, developers, testers, product managers, and engineers, all working together to make something feel effortless for the rest of us.

And honestly, that's something I had never appreciated until I looked behind the screen.

Exploring QApilot Made Me Think Differently About Testing

By this point, I had stopped looking at testing as just another step before releasing an app. Instead, I started seeing it as something that builds confidence not just for the team creating the app, but for the people using it.

That's when I spent more time exploring QApilot itself.

What I liked immediately was that I didn't need to be an experienced QA engineer to understand the platform. The interface felt simple enough to explore without constantly referring to documentation, which made learning much easier.

The first feature that caught my attention was the Crawler.

Initially, I thought it would simply click random buttons. But I soon realized its purpose was much more practical. It explores an app the way a curious user might, moving through different screens and uncovering user journeys you may not think of manually.

Then came Record & Play.

It made me think about how repetitive testing can become. Every new release often means repeating the same login flow, navigation, or validation steps. Instead of doing those tasks from scratch every single time, Record & Play allows testers to automate the repetitive parts and spend more time exploring new features and unexpected scenarios.

The feature that stood out to me the most, though, was CoWork.

Whenever people talk about AI, the conversation usually becomes, "Will it replace people?"

CoWork gave me a different perspective.

It felt less like AI replacing testers and more like AI working alongside them. It helps generate and organize test cases, while the tester still reviews, guides, and makes the final decisions. That balance made much more sense to me than expecting AI to handle everything on its own.

Exploring these features made me realize that modern testing isn't just about finding bugs anymore. It's about making the entire testing process smarter, faster, and easier without taking people out of the equation.

If It Can Help a Vibe Coder, Imagine What It Can Do for QA Teams

One thought kept coming back to me while I was learning all this.

Building software has become easier than ever.

Today, someone with an idea can use AI coding tools or vibe coding platforms to build a working app in days instead of months. That's incredible because it allows more people to bring their ideas to life.

But building an app is only half the journey.

Making sure it's reliable is something entirely different.

Users don't care whether an app was written by an experienced engineer, a solo founder, or an AI coding assistant. They only care about one thing, it should work.

If the app crashes during a payment, freezes during onboarding, or breaks on a particular device, most users won't wait for an explanation. They'll leave a poor review or move on to another app.

That's where I started seeing the bigger value of testing.

If I were building my first app today, I'd want to know whether the important user journeys worked before anyone downloaded it. I'd want someone or something to explore the app the way a real user would and point out issues I might have missed.

That's exactly why tools like this make so much sense for startup founders and indie developers. They provide confidence before launch.

And if they can simplify testing for someone with little experience, I can only imagine how much more useful they become for professional QA teams managing hundreds of test cases, multiple releases, and different devices every day.

For me, that was the biggest takeaway.

AI isn't replacing testing.

It's helping people spend less time repeating the same work and more time solving the problems that still need human thinking.

The Next Time My Phone Asks Me to Update...

It's funny how quickly a perspective can change.

A few months ago, an app update was just another interruption. I'd tap "Update Later" and continue with whatever I was doing.

Now, whenever I see that notification, I think about everything that probably happened before it reached my phone.

Someone may have discovered a bug that only appeared on a particular device.

Someone may have found an issue while testing a user flow that nobody expected.

A designer, developer, tester, and product team may have worked together to fix it before millions of users ever noticed. Most of that work is completely invisible. And maybe that's the whole point. When an app works smoothly, we don't stop to appreciate the effort behind it. We simply expect it to work. This experience didn't turn me into a QA engineer. It did, however, turn me into a much more curious user.

Now, whenever I open an app, I find myself wondering about the work happening behind the screen. How many scenarios were tested before this feature reached me? How many conversations happened before this button behaved exactly the way it should? How many problems were solved before I even had the chance to experience them? Those are questions I never would've asked a few months ago.

The next time my phone asks me to install an update, I'll probably still wish it had chosen a better time.

But instead of thinking,

"Why another update?"

I'll probably think,

"Someone found a problem before I did and they're making sure I never have to experience it."

As users, we only see the finished product.

Behind every smooth experience is an enormous amount of invisible work.

And after getting a glimpse of that world, I don't think I'll ever look at app updates or mobile apps the same way again.

The FinTech Exception: Why Your Green Test Suites Are Still Missing Mobile Login Crashes

Harini Mukesh — Thu, 04 Jun 2026 05:30:00 +0000

You are sitting at your desk late on a Tuesday night.

Your automated test suite is completely green. Every single end-to-end script passed on the CI/CD server, and according to your dashboard, the code is flawless.

Yet, you are still surrounded by Android and iOS devices scattered across your desk. You are manually unlocking them, opening your app, typing verification codes, validating masked customer data, checking authentication workflows, and repeatedly running through the same critical user journeys.

Your eyes are heavy, the clock is ticking past midnight, and you are asking yourself a fundamental question:

If our automation is so advanced, why am I still doing this by hand?

This is the silent reality inside many mobile engineering teams building high-security applications.

It is what we call the FinTech Exception.

Teams build sophisticated automation pipelines for their core product experiences. Account creation works. Transactions work. Dashboard validations work. API integrations work.

But the moment applications introduce biometric authentication, face recognition, multi-factor authentication, OTP verification, personally identifiable information (PII), data masking requirements, compliance controls, or operating system managed workflows, things start becoming significantly more complicated.

Traditional automation frameworks such as Appium remain powerful tools and continue to serve countless engineering teams successfully.

The challenge is not that these workflows are impossible to automate.

The challenge is everything required to automate them reliably.

Authentication workflows often depend on device farms, custom integrations, environment-specific configurations, security exceptions, test credentials, external authentication providers, operating system behavior, and a growing collection of supporting infrastructure.

A fingerprint validation may depend on one setup.

Face recognition may require another.

Masked customer data may require specialized handling.

OTP validation often introduces additional dependencies.

PII-sensitive workflows frequently need separate controls to remain compliant.

Each individual solution may work.

The problem is that engineering teams slowly accumulate dozens of these solutions over time.

What begins as a simple automation framework gradually evolves into a complex ecosystem of scripts, integrations, exceptions, mocks, device configurations, and maintenance overhead.

The result is familiar to almost every mobile QA team.

The dashboard stays green.

Confidence does not.

The Real-World Friction Point

Eventually, the gap between test environments and production reality catches up.

The mobile ecosystem has seen multiple examples over the years where authentication, login, onboarding, and session-related issues slipped into production despite extensive testing efforts.

One example was the widely reported login and stability issues experienced by users of the digital credit card platform OneCard following an application update.

While the exact root cause was never publicly disclosed, incidents like these highlight an important reality of modern mobile engineering:

Some of the most critical failures occur at the intersection of application logic, authentication systems, operating system behavior, device fragmentation, and real-world user conditions.

These are rarely simple defects.

They are often the result of complex interactions across multiple systems.

Authentication flows alone can involve:

Session management
Device-specific behavior
Security libraries
Biometric providers
Operating system updates
Network dependencies
Identity providers
Compliance controls

Every additional layer increases the number of possible failure points.

This is what makes mobile quality fundamentally different from web quality.

In a web application, a broken login experience can often be patched and deployed within minutes.

Mobile software operates on a completely different timeline.

A production issue typically requires:

A code fix
A new build
Store submission
Platform review
User adoption

Even after approval, users still need to install the update.

If the issue impacts onboarding, authentication, or application launch, many users may never return.

For financial applications, the stakes become even higher.

A bug in a social platform might prevent someone from viewing content.

A bug in a banking application can prevent customers from accessing their money.

Redefining How We Approach Mobile Quality

The natural reaction to this complexity is to add more automation.

More scripts.

More integrations.

More mocks.

More device configurations.

More validation layers.

Yet many teams discover that complexity grows faster than coverage.

The challenge is no longer executing tests.

The challenge is understanding application behavior at scale.

This is where a different approach begins to emerge.

Instead of treating mobile quality as a collection of scripts and test cases, modern platforms are increasingly introducing intelligence layers that sit above traditional automation infrastructure.

This is the philosophy behind QApilot.

QApilot does not attempt to replace the underlying ecosystem of device farms, testing infrastructure, CI/CD pipelines, authentication services, and execution environments that engineering teams already use.

Instead, it acts as an autonomous intelligence layer that helps orchestrate, understand, and validate application behavior more effectively.

Rather than relying exclusively on predefined scripts, selectors, and manually designed test paths, QApilot evaluates production-ready application binaries and continuously builds a dynamic understanding of how the application behaves.

The platform maps screens, user journeys, navigation paths, application states, and user intent into a living knowledge graph.

This creates a fundamentally different testing experience.

A traditional test script follows instructions.

An autonomous testing system understands context.

A crawler explores screens.

An intelligent crawler understands relationships between screens.

A test case validates an expected path.

An autonomous system continuously discovers new paths.

Instead of asking:

"Did this specific script pass?"

Teams can begin asking:

"What does the application actually do?"

That shift becomes increasingly valuable as applications grow in complexity.

Authentication systems evolve.

User journeys expand.

New compliance requirements emerge.

Security workflows become more sophisticated.

The cost of maintaining manually curated automation suites continues to increase.

An intelligence-driven approach helps absorb that complexity.

Instead of constantly updating brittle scripts whenever interfaces evolve, teams gain a system that understands the application itself and adapts alongside it.

Beyond Automation Execution

This is ultimately where many conversations around mobile quality are heading.

The industry has spent years focusing on how to execute tests.

The next evolution is understanding how to reason about applications.

Execution engines are important.

Device farms are important.

Authentication integrations are important.

Biometric testing support is important.

But those components alone do not create confidence.

Confidence comes from understanding application behavior across thousands of possible states and interactions.

That is the layer QApilot is designed to provide.

And the results are already becoming visible.

One of the largest digital banking organizations in the Middle East leveraged QApilot to significantly accelerate automation coverage while reducing maintenance overhead across critical mobile workflows.

The value was not simply running more tests.

The value was achieving broader validation with less operational effort.

As mobile applications continue becoming more security-conscious, compliance-driven, and operationally complex, this distinction becomes increasingly important.

The Ultimate Takeaway

The FinTech Exception exists because modern mobile applications are no longer simple collections of screens and workflows.

They are interconnected systems involving authentication providers, biometric services, compliance controls, security layers, device-specific behavior, and constantly evolving operating systems.

The challenge is not whether these workflows can be automated.

They can.

The challenge is maintaining confidence as complexity continues to grow.

Traditional automation solves execution.

The next generation of mobile quality platforms is focused on understanding.

That is the shift autonomous testing introduces.

And for engineering teams building the next generation of financial applications, it may be one of the most important shifts in software quality today.

Security Reports That Ship With Your Release: The QA Checklist Teams Ignore

Harini Mukesh — Thu, 28 May 2026 10:30:00 +0000

There's a ritual that happens before almost every mobile app release. The QA team runs through their checklist. Test cases pass. Regression looks clean. The PM gives the thumbs up. The build ships.

And somewhere in that process, nobody checked if the app was running with a debug certificate. Nobody looked at whether microphone access was being requested for a feature that doesn't need it. Nobody noticed that three broadcast receivers were left open to any other app on the device.

Not because the team was careless. Because that's just not what the QA checklist looked like.

I've been thinking about this gap a lot lately, and I want to walk through what a security-aware QA process actually looks like for mobile apps, why most teams skip it, and what changes when security issues land right next to your functional test results.

Why Security Stays Off the QA Radar

The honest answer is that security testing has always lived in a different lane. You finish QA, hand off to a security team (if you have one), they run a scan separately, findings come back in a spreadsheet, and by that point the release is already being pressured. Anything non-critical gets deferred to "next sprint."

The problem isn't intent. It's tooling and process. When security issues live in a separate tool, with a separate workflow, most QA engineers never see them. And if you don't see them, you can't include them in your release sign-off.

What Static Analysis Actually Checks (And Why QA Should Care)

When you run a static analysis scan on a mobile APK, you're not running the app. You're reading the package itself. Think of it like auditing a building's blueprints before anyone moves in. You're looking at what permissions were declared, how components are wired together, what's baked into the binary.

Here's what the main categories of issues actually mean in plain terms:

Permissions

The app declares what device features it wants access to. Some of these are fine, internet access, vibration. Some are dangerous, fine GPS location, record audio, read contacts. The question isn't just "does the app need these" but "does it need all of these, and are they justified?" An app requesting microphone, fine location, and boot-on-start permissions together is worth looking at twice. OWASP's Mobile Top 10 lists over-privileged apps as one of the most common and exploitable issues in mobile security.

Manifest misconfigurations

The manifest is a config file every Android app ships with. It declares what the app is allowed to do, what components it has, how it talks to the OS. Issues here include cleartext traffic being allowed, the app supporting dangerously old Android versions, and components being accidentally left open to other apps. None of this is code, it's all configuration, but it can cause real damage.

Certificate issues

Every app has to be digitally signed before it can be distributed. During development you use a debug certificate, which is loose and meant for testing. Before production you're supposed to swap it for a proper production certificate. A debug certificate in a production build is a high severity issue, and it's exactly the kind of thing that slips through when nobody is looking.

Hardcoded secrets

API keys, tokens, and credentials sometimes end up baked directly into the app binary during development. Static analysis surfaces these. They shouldn't ship.

Tracker detection

Third-party SDKs bundled into the app, analytics, advertising, crash reporting, are catalogued. This matters for privacy compliance and gives you a clear picture of what data is being collected and where it's going.

A Real Example Worth Paying Attention To

This one happened earlier this year, and it's a good illustration of why the hardcoded secrets check isn't just housekeeping.

In April 2026, security researchers at CloudSEK scanned the top 10,000 Android apps and found 32 Google API keys hardcoded across 22 popular applications with a combined install base of over 500 million users. Apps like OYO, Google Pay for Business, and ELSA Speak were in that list.

Here's where it gets interesting. These API keys were not embedded by mistake. Developers followed Google's own documentation, which had long classified that key format as safe for client-side use. But when Google enabled Gemini on these projects, every existing API key on the project silently inherited access to the AI endpoints. Keys that were harmless became live credentials to one of the most powerful AI systems in the world, overnight, without any code change on the developer's side.

Researchers confirmed actual data exposure in at least one case, accessing user-uploaded audio files through an exposed key. And the billing damage from similar exposures? One solo developer lost $15,400 in a single night. A team in Japan was hit for roughly $128,000.

The thing that stays with me about this is that a static analysis scan would have flagged these keys. Not because the scan knew Gemini was going to become a problem, but because hardcoded keys are a known issue regardless of what they currently access. The checklist item existed. The check just wasn't happening consistently.

Here's How QApilot Handles This

This is where I want to show rather than tell. QApilot generates a security report alongside every test run automatically. No separate tool, no handoff, no extra setup beyond flipping one toggle when you upload your app.

This video walks through what that actually looks like in practice, from enabling the toggle to reading the issues across Manifest Analysis, Certificate Analysis, and Code Analysis.

What I find useful about this is the Recommendation column. It doesn't just tell you something is wrong. It tells you exactly what to change and where. That's a different experience from receiving a spreadsheet of issues after code freeze, when nobody wants to reopen anything.

And when the report lives next to your functional test results, it stops being something you defer. A HIGH severity issue sitting next to two failed test cases gets treated the same way a failed test case does. It becomes part of the release conversation, not an afterthought.

The Bigger Point

I'm not saying every QA engineer needs to become a security expert. That's not realistic and it's not the point.

The point is that there's a category of issues that are consistently skipped before release, not because they're hard to find but because nobody set up the workflow to look for them. A debug certificate, an over-privileged permission, a misconfigured manifest component, these are not subtle vulnerabilities. They show up immediately in any static scan. They just don't show up in the QA checklist.

The CloudSEK example is a good reminder that the cost of skipping this check doesn't always look like a traditional breach. Sometimes it's a billing spike that hits overnight. Sometimes it's user data sitting in an accessible cache that nobody knew was exposed. The common thread is that the risk was well understood, and the check still wasn't part of the release process.

Adding security to your release process doesn't have to mean a major overhaul. It can start with one toggle and one more report in your test run. That alone catches the obvious stuff before it ships.

Have you ran a static analysis scan on your mobile app before? Curious what you found, or what surprised you. Drop it in the comments.