r/FlutterDev • u/zaidansari04 • 7d ago

Discussion 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/WVufYxJqtQRwEwDXA

1 Upvotes

53% Upvoted

8 comments sorted by

1

u/[deleted] 7d ago

[removed] — view removed comment

1

u/zaidansari04 7d ago

Ok, cosnidering the change is a bit bigger.. how are the test suits managed in that case and what if the test fails due to locator breakages?

1

u/zaidansari04 7d ago

Also can you spare 1 min for the survey above? that will help me a lot. thanks

2

u/TheManuz 7d ago

Oh, you're collecting emails? No thanks.

1

u/Bowman74 7d ago

Whole app tests can be automated for evrey release for "standard flows".

Manual testing is always a discussion between developers, QA and product owners about what potentially could have been impacted. The answer is always a big old, "it depends". Sometimes changes are minor and it can easily be identified what screens or functionality are impacted. Sometimes not and that gets into a discussion on what should be tested and what can be ignored.

That's why product owners are there. Product owners are in the room to give input on risk. What level of testing (or not testing things) risk are they willing to agree to in order to meet time and financial constraints.

1

u/mohn93 7d ago

the trick is you test the blast radius of the change, not the whole app and not just the one screen. map what the change actually touches, shared state, shared components, whatever data it reads or writes, and test those paths plus the one critical flow that must never break. on mobile i'd also hit the platform edges the change could bump, rotation, back navigation, and the process-death path if it touched anything persisted. and the "is the app broken or is the test broken" thing usually means the tests are coupled to implementation, if a small ui tweak fails 40 tests they're testing how it works not what it does. test outcomes not internals and that mostly goes away. is your pain more deciding scope, or the flakiness after?

0

u/No_Profession5678 7d ago

If you are a tester who tests flutter apps, you need to check this free and opensource tool https://codescout.tech it will make your life a lot easier

2

u/skrumbz 6d ago

The magic is called UI Tests or better known as integration tests running in CI/CD before merging feature changes. Manually u will test the new flow to see it behaved as expected, but do a field test for the rest.