More Than Just Tapping Around: How to Build a Toolkit for Manual Mobile Testing — from Bash Scripts to AI

I’ve been working in mobile testing since 2014. Over that time, device hardware has become faster, Android has grown more complex, yet many testing habits have barely changed.

To install a build, a tester keeps a Bash script somewhere. To change a particular setting, they spend time searching for it on the device. Usernames and passwords live in notes. Test data is stored wherever convenient — or not stored at all. The team tracks its devices in a Google Sheet or Confluence. Sometimes, running a single simple command requires installing Android SDK Platform-Tools or even the entire Android Studio.

Each of these problems may seem minor on its own. But over the course of a day, they add up to a great deal of unnecessary work. Worse still, a bug report may reach a developer without some of the essential context. The device model was not included. The build number was forgotten. No one recorded whether dark mode was enabled. The data that caused the input form to fail was not saved. Log collection started only after the crash.

At first, I tried to solve these problems one by one. I wrote a script for one task, saved a command for another, and made a note for a third. Eventually, I realized that the problem was not the lack of yet another script. What we needed was a simple tool for the entire team — one that would help us preserve everything that happened during testing. So why not build it?

In this talk, we’ll explore several everyday scenarios. We’ll prepare a device; change its language, theme, and network settings with a single click; install an APK; and identify the exact build version. We’ll revoke permissions, enable logcat in advance, and save the stack trace after a crash. We’ll work with test data and preserve it for the next test run. We’ll discuss test accounts and passwords that are usually copied and pasted manually from notes. I’ll also show how to maintain a device library that gives you an honest answer to a simple question: which devices can the team actually use to test the application?

Finally, we’ll look at how all of this can be done through an MCP interface, allowing an LLM to control the device, collect logs, and prepare a report.

This talk is about turning “it crashed” or “it doesn’t work” into a clear, developer-friendly story that provides everything needed to start fixing the defect immediately.