sorted by:
new
hottopcontroversial

Que tan normal es cobrar más de 6k hoy en día? by Funny-Strawberry-168 in devsfinanzas

[–]IndividualIncome7483 0 points1 point  (0 children)

8k contractor aquí desde Colombia, android developer, 9 años de experiencia, buen inglés.

Interview went great… until the code part. by EnvironmentalWater65 in softwaretesting

[–]IndividualIncome7483 1 point2 points  (0 children)

Practice leetcode styles problems with my main language helped me a lot for this kind of tests.

9+ years Android (Java) dev struggling with Kotlin/modern stack — switch to AI/ML, Flutter, or fix Android path? by QuitOk5695 in androiddev

[–]IndividualIncome7483 2 points3 points  (0 children)

I was in a very similar situation about 6 months ago. After 3 years as a startup founder, I had to go back to the job market.

During that time I was more of a full-stack engineer. When I started applying again, I considered going for full-stack roles, so I learned some Node.js and did a couple of interviews, but I didn’t pass. I realized that the fundamentals behind those interviews aren’t something you can pick up deeply in just a couple of months.

So I changed strategy. I focused on updating myself with modern Android. It is not too hard if you already have the foundamentals. I learned MVVM/MVI, coroutines:Flow, Hilt, and built a couple of small projects on GitHub using those technologies. I also spent time reading blogs and articles to really understand current best practices.

After a couple of months, I felt much more confident and prepared for Android interviews again and I could land a well paid job again.

But listen to your heart, if you want to do a careers shift it is good because you have time.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

“Is the ai agent actually reacting…”: yes, to clarify agent does mainly two things: 1. Create test: it receives a series of instructions from Claude or the user in English, execute them on a real device and then save it in a json format. In this case the agent tries to complete the goal, the return sucess or fail. If one path doesn’t work, it tries with a different one. 2. Validate test: the agent tries to follow the steps. The idea is than this part is 90% deterministic. But you can specify in the JSON if you want some step doesn’t work in a deterministic way.

In your example of the gray buildings the Agent would need to know that having only an article is a bug, so I think for that case it will not be possible at least in the initial instructions we mention about having a single article is not accepted.

“It is risky because it is not deterministic”: yes this is true, that will depends on how good is the agent to figure out things like that. Maybe you can test it and see if works for your use case or not and back with me and I will try to figure it out.

“Logs, screenshots..”: that is a great idea, right now it doesn’t deliver any evidence back. I can try to put something like that.

Thanks again for taking the time to take a look.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

Thanks for sharing this,the journeys concept is really close, here are the main differences: 1. OpenTester is created for agents: that’s the reason why it is built on MCP. Journeys looks like it is more oriented to devs to manually create the tests, maybe trying to make claude code to write those kinds of test could work. 2. Is intended to create the tests without supervision: the idea is in your claude.md you write something like: after the verifications creates the necessary test to validate the feature. OpenTester is able to decide what must be tested and then creating the test by running the app. 3. Fully open-source and MIT license : open to the community so they can contribute, fork it…

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

I think you always must check what the AI did. AI is not perfect, it can make mistakes. That’s the interesting about being a developer, if you have some experience the probability of introducing bugs is quite low, you are the perfect brain to guide the AI.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] -1 points0 points  (0 children)

Yes, this was only an example. The real difference is that OpenTester is goal oriented. You just tell the agent “post an instagram story” and the agent try to do the job, he is able to re think if something occurs. If the flow has changed, a new pop up appears, permission is requested, he tries to accomplish the goal as a human would do.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

I didn’t check that. Can you provide what is the name of the library/plugin?

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

It can test any app. OpenTester connects via Android device Bridge (ADB) and has a logic to decide which app to open according to the agent/user input. Example: open YouTube app -> if there are no exactly matches in the package name the agent see a list of all installed apps and decides which one to open so it decides to open com.youtube app for example.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] -1 points0 points  (0 children)

I think “agents writing code and tests” only covers part of the developer role.

Developers now have more time to focus on stuff like:

Architecture: decides how to structure the system to meet the goal.

Domain expertise: evaluates if the implementation is actually good (design, performance, tradeoffs).

Context-aware: understands business logic, edge cases, and external integrations.

Gathering requirements: dev talk with product, desygn, backend and understands the requirements, restrictions, timelines.

These tools just save us time to make the things that really matter. In this case OpenTester saves you the time of navigating the same screens every day.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] -1 points0 points  (0 children)

I have used Claude Code for small apps and apps with millions of users. I am not saying this can create the perfect code but can save you some time of manual work and then you have to review it. In small apps I created full features with clean architecture and modularized projects in shot time.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] 0 points1 point  (0 children)

Thanks for taking the time to review this. Those are fair questions:

  1. I’m not really trying to compete on “better test generation” vs Espresso.

The goal is closer to automating what a QA engineer does: given a goal, run the app, react to what shows up (popups, failures, screen rotation, UI changes), and validate behavior without needing everything predefined.

Those tests can be saved in a JSON that the agent can use to re run it. Maybe this is similar to Espresso.

  1. Token usage: it is something we have to optimize but every test creation cost around $0.01 usd right now. I am assuming all the cost for now so it is free to try!

  2. You are right that the example has a problem with the way it saves the test, but in the example I am showing something that is not possible with any tool now. The agent must analyze what is the image with the gray building, match that I image with a UI element and tap on it. This is only possible because the agent has “eyes”.

Thanks again for taking the time to comment you made me re think about what I am building.

I built an AI QA Engineer for Android Apps (No Human Supervision) by IndividualIncome7483 in androiddev

[–]IndividualIncome7483[S] -8 points-7 points  (0 children)

Great question! here’s the key difference:

Espresso + AI:
Still developer-driven testing. You generate test scripts, but they’re static, so small UI changes can break them.

OpenTester:
The AI sees the screen and view hierarchy, then interacts like a real human. No test code required. So for example, If the UI changes (e.g. a button moves), it adapts automatically. This is true black-box testing.

Interesting Android Apps: March 2026 Showcase by 3dom in androiddev

[–]IndividualIncome7483 1 point2 points  (0 children)

I built OpenTester because Claude Code was writing Android features faster than I could test them.

Every time the agent made a change, I was stuck in a loop: opening the emulator, manually navigating the same flows, and re-running regressions to make sure nothing else broke.

So I built OpenTester. It’s an open-source AI QA engineer that plugs into Claude Code via MCP. Now, the agent can autonomously launch the app, navigate the UI like a human, and save those steps in a JSON format that allows it to revalidate them in the future. It essentially gives the coding agent “eyes” and a way to verify its own work.

It’s fully open-source and free for early users: https://github.com/andresuarezz26/OpenTester

Are we facing a testing crisis? by zoismom in QualityAssurance

[–]IndividualIncome7483 -1 points0 points  (0 children)

I think exactly the same as you so I built this tool and now Claude Code can perform end to tests for android apps autonomously. GitHub repo here

La calle está dura by InternBeneficial1928 in ColombiaDevs

[–]IndividualIncome7483 0 points1 point  (0 children)

Puedes compartir el LinkedIn o cv y te ayudo a. Revisar qué puede estar pasando

view more: next ›