DEV Community: Harini Mukesh

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.