What automated tests actually check
An automated test is code that taps buttons, enters data and confirms the right result appears on screen. It works best on flows that repeat from release to release and matter to revenue. Typical examples:
The real value is protection against regressions. A developer adjusts a catalog filter and, as a side effect, the cart stops opening for customers. That kind of hidden link is easy to miss by hand, while a set of tests catches it before the update reaches the store.
- signing in with a phone number and an SMS code
- search and filters in the catalog
- adding items to the cart and placing an order
- paying through Click or Payme in test mode
- saving a profile and delivery addresses
What manual testing still does better
People are needed wherever feel matters. Can the main button be reached with a thumb, are prices in soums readable on a small screen, does an animation get annoying? An automated test will not notice that a promo banner covers the order button unless someone wrote exactly that check.
New features are also reviewed by hand first. While a screen changes every day, writing tests for it is premature because they would need constant rewriting. A sensible split is manual review for new features and visual quality, and automated checks for the stable core of the app.
When mobile app test automation pays off
The decision rests on two questions: how often do updates ship, and how much does a bug in production cost? An online store or delivery service with daily promotions and in-app payments will almost certainly benefit, because each release is checked quickly and a payment failure hits revenue directly.
A simple brochure-style app for a clinic or salon that is updated a couple of times a year can often get by with manual checks. Automated tests also need upkeep: when a screen is redesigned, its tests must be fixed. That is why it is better to begin with a handful of critical flows rather than try to cover everything at once.
Android, iOS and real conditions in Uzbekistan
Even when an app is built on a shared codebase such as Flutter or React Native, each platform is tested separately. Permissions, push notifications, gestures and returning from the background behave differently. iOS needs Apple devices or simulators and attention to App Store requirements, while Android needs a spread of manufacturers and system versions.
Many people use budget smartphones with limited memory, so testing only on a new flagship is risky. Poor connectivity deserves its own checks: mobile internet in the regions, switching from Wi-Fi to mobile data, a dropped connection right after tapping Pay. The customer should never be charged twice or lose an order.
Security is a separate job
If the app handles payments or personal data, security is checked apart from ordinary features. Some scenarios can be automated, for example confirming that other people's orders are unreachable without signing in. Unusual ways around the app's logic are more often found by a specialist working by hand.
The check is repeated after significant changes to authorization or data handling, rather than relying on a result from before the first launch.
Where to start
There is no need to build a large system on day one. A practical order looks like this:
Testing should not wait for the end. Critical flows are checked as they become ready, while a mistake is still cheap to fix, and a final pass on real devices happens before publishing.
- list the flows where a failure costs you money or customers
- check them manually and write down the expected result
- automate the most stable and most frequent ones
- build a list of devices your customers actually use
- run the tests before every release, not once a quarter
- add a test for each bug found in production
The app, the website and the bigger picture
Most apps sit alongside a website, an admin panel or an API, and the whole chain has to be verified: an order placed in the app must appear in the manager's panel, and its status must travel back to the customer. This is why markdev treats testing as part of development, including when we build websites on a turnkey basis, rather than a step bolted on at the end.
If you are trying to decide whether automation makes sense for you and which flows to cover first, tell the markdev team about your project and we will go through your case without a template.
FAQ
Does a small app need test automation?
Not necessarily at the start. If the app is simple and rarely updated, manual testing is usually enough. Automation becomes worthwhile once releases become regular.
Is manual or automated testing better?
They solve different problems. Manual testing is more flexible for judging usability and looks, while automated testing repeats the same checks quickly on every update. Most teams use both.
Do I need separate testing for iOS and Android?
Yes. Even with a shared codebase, the two systems handle permissions, notifications and gestures differently, so each platform is checked on its own.
Is security testing part of regular testing?
It is a separate area and is best discussed when the task is defined, especially if the app handles payments or customers' personal data.
Let’s look at your task for free
Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.