DEV Community: Harini Mukesh

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.