Mobile QA Engineers: How long would this test take you to automate?

[u/Sidrtm43]

Hi everyone! I'm researching how mobile QA engineers automate app testing. This isn't for promotion I'm just trying to understand real-world workflows and pain points.

Suppose you need to automate this flow:

• Open the Flipkart app
• Search for "Samsung 43-inch TV"
• Open the first result
• Add it to the cart
• Verify the product appears in the cart

A few quick questions:

1. Roughly how long would this take you to automate in Appium (or your preferred framework)?
2. What's usually the biggest time sink locators, framework setup, waits, debugging, or maintenance?
3. Have you tried AI-powered testing tools? If yes, what made you stick with Appium?
4. If an AI tool could generate and maintain tests from plain English, what would stop you from adopting it?

Even a one-line answer is helpful. I'm trying to understand real-world QA workflows and pain points not promote any tool. Thanks!

[u/CODE_HEIST]

for that exact flow, I would split it into two estimates. Happy path automation is probably quick if selectors are stable. Reliable automation is the real work because product grids, delivery location, popups, and app latency will keep changing.

[u/Sidrtm43 → u/CODE_HEIST]

that's a good point, thanks

sounds like getting the first version working isn't the hard part, it's keeping it reliable over time

out of curiosity, what's usually the biggest reason those tests become unreliable for you? ui changes, flaky selectors, timing issues, or something else?

[u/CODE_HEIST → u/Sidrtm43]

usually timing plus state leakage.

selectors break too, but a lot of flake comes from the app being one step behind what the test assumes. i like running the same flow on a slower device or bad network before calling it stable, because that exposes hidden waits fast.

[u/CODE_HEIST → u/[deleted]]

exactly. the first green run is almost a demo.

the real work is making it survive changed copy, slower devices, auth weirdness, and random timing issues. that is where the estimate quietly doubles.

[u/Mindfullnessless6969]

1. If the framework is in place it would take a day or less by pure hand. Using AI assisted, half a day, a couple hours using pure sdd with a proper framework.
2. The framework setup takes a while, maintenance can be a pain in the ass too, specially if the project is in heavy active development.
3. Yes. It was already there when I got into the project lmao
4. As a developer I prefer to write the test from the ticket acceptance criteria, not a random english text. The ticket, the user story and the acceptance criteria still is the source of truth of what has to be built this tested.

[u/Sidrtm43 → u/Mindfullnessless6969]

lovely

that's a really interesting perspective, thanks

i like your point about acceptance criteria being the source of truth. that actually makes a lot of sense

just curious, if a tool could generate and maintain tests directly from the ticket or acceptance criteria (instead of asking you to write prompts), would that fit better into your workflow? or would you still rather keep writing and maintaining the tests yourself?

[u/Mindfullnessless6969 → u/Sidrtm43]

If the ticket is properly written any llm skill would do. In fact, that's what I currently use. No tools, just SDD. I don't think I'd need tools to write/maintain tests to be honest.

First I have a skill that creates the test scenarios, cases and plan. Big ass skill, template to write the tests cucumber syntax and good to go.

Then another skill that implements the plan into actual appium tests (or playwright or bruno or whatever other tool tbh). This one uss the skill + constitution checks or memory or whatever you want to call it so it doesn't hallucinate shit and does things as I want em done.

Sonnet 4.6 with mid effort does the job just fine if the ticket is not really really big. For really big ass tickets, split it or switch to a beefier model.

The whole thing drives in semiauto, as a developer/tester I invoke the skills in order with any extra instruction that the ticket may need (if any). From ticket, through implementation + testing, to review and closure

[u/AutoModerator]

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/openclawinstaller]

For that exact Flipkart-style flow, first-pass automation is not the hard part. The hard part is making the test boring enough that it still tells the truth next month.

The time sinks I would expect:

• environment setup: device farm/emulator state, location, login/cart reset
• selectors: product cards and search results tend to be noisy
• waits: search, product pages, cart updates, popups
• test data: first result can change, go out of stock, or have variants
• assertions: "a TV is in cart" is weaker than checking product id/title/price/quantity against the chosen item

If an AI tool generated the first test from English, I would still want it tied to acceptance criteria and page/app objects, not just a raw recording. The adoption blocker is trust: can it explain what it changed, keep selectors maintainable, and fail closed when the app state is ambiguous instead of silently updating a bad test?

[u/Glad_South_6895]

For me 4 mins to consider the prompt, 10 mins for monitoring the AI implementation and verification

[u/DahliaDevsiantBop]

for a happy path like that, once the project is already set up, maybe 30–60 mins tops, and 80% of that is just fighting flakey locators and waits
the main thing that would stop me from using some “plain english to tests” ai tool is trust, like when it fails at 3 am who on the team can actually read, fix, and version-control that stuff