In this guide
You have limited time. Automated tests are cheap to run again and again; manual testing finds what you did not think to check. The question is not which one, but what goes where first.
Criteria
| Criterion | Automated (unit, UI) | Manual (you or others) |
|---|---|---|
| Good at | Logic that must keep working: calculations, parsing, state, regressions | Usability, confusion, layout on real devices, "does this feel right" |
| Upfront cost | Writing and maintaining tests | Little setup |
| Cost per run | Close to zero | Your time every time |
| Weak at | Anything you did not encode; UI tests can be fragile | Repetition: people skip steps and tire |
| Finds surprises | Rarely | Often |
What to automate first
- Pure logic with clear inputs and outputs: pricing, formatting, sync rules, data migration.
- Bugs you have already fixed. One test per fixed bug stops it returning.
- Critical paths that would hurt most if broken: sign-in, purchase, saving data. Keep these few.
What to leave to people
- First-run experience and onboarding
- Layout across screen sizes and OS versions you actually target
- Wording, flows and anything a user may misunderstand
- Interruptions: calls, poor connection, low battery, background and return
A simple routine
Before each release: run the automated set, then do a short manual pass on the critical paths on one real device. Every few releases, bring in outside testers who have never seen the app, since you can no longer see your own blind spots.
Where AppReviewX helps
Outside testers cover the manual side you cannot do on your own. On AppReviewX, other developers give private, structured feedback on your published app; 1 accepted feedback = 1 credit and new accounts start with 0. It does not replace your automated tests.
Related: all testing options, alpha vs beta vs release candidate, beta test vs soft launch.