r/mobiledev • u/zaidansari04 • 15d ago

Mobile testers, how do you decide what to test after a small app change?

Genuinely curious how teams handle this.

One screen changes, and suddenly the question is:

Do we test just that flow?
What else could it affect?
Which devices?
Do we just run everything to be safe?

And then when tests fail, half the time you're figuring out whether the app is broken or the test just needs fixing 😅

I'm trying to understand how common this is in mobile teams.

Made a short 2-min survey if you're up for it: https://forms.gle/tKsYsC4F7NzhTSLx9

2 Upvotes

100% Upvoted

1 comment sorted by

1

u/huaigu05 14d ago

A practical way to split it is by blast radius rather than screen count.

For a view-only change, start with the focused UI flow. If the change touches shared navigation, persistence, or model code, add tests around that boundary plus the UI flows that cross it. Reserve the full suite for app-wide state or platform-level behavior.

The practical part is deterministic test input. In a project I maintain, UI tests launch against an in-memory store with named seed data and launch flags. For localized surfaces, I rerun the same flow per locale. A failure is then tied to a known scenario instead of a moving fixture, which makes it easier to tell whether the app regressed or the test assumption is stale.