Web and Mobile Application Testing
A web portal and a native mobile app fail in different ways and need different checks. GullySystem tests both, from browser forms to phone permissions, offline storage and app-store upgrade paths, on the platforms your users actually carry.
Two Platforms, Two Sets of Failure Points
A web application depends on the browser, the network and whatever else is open in the same tab. A mobile application depends on the operating system version, the phone's storage and battery state, background permissions, and what happens when a call interrupts the app mid-action. Testing one well does not test the other — each needs its own checks against how people actually use it.
What Web Testing Covers
Forms and Validation
Required fields, formats, and error messages checked against what a real customer types, not just the value a developer expects.
Session and Navigation
Back button, browser refresh, multiple tabs open at once, and session timeout mid-transaction.
File Handling
Uploads, downloads, printing and exports checked for size limits, formats and what happens when they fail partway.
What Mobile Testing Covers
Install and Upgrade
Fresh installs, upgrades from an older version, and what happens to data already stored on the device across that upgrade.
Permissions and Notifications
Camera, location and storage permissions granted, denied or revoked mid-session, and notifications delivered while the app is closed.
Interruptions and Low Resources
An incoming call, a low battery warning, low storage, or the app pushed to the background mid-transaction.
Offline and Sync Behaviour
Actions taken with no signal, and what happens when the connection returns and queued data tries to sync.
A Restaurant Delivery App, as an Example
A restaurant chain's delivery app is tested for a customer placing an order on a weak signal near a basement kitchen, an incoming call arriving mid-checkout, and the app being force-closed and reopened before the order confirms. On the web side, the same chain's admin portal is tested for a manager editing today's menu in one browser tab while a second tab still shows the old prices to a customer checking out.
Frequently asked questions
Do you test on real phones or only emulators?
Primary combinations are tested on real Android and iOS handsets, because emulators do not reproduce battery, signal and interruption behaviour accurately. Emulators and device cloud services extend coverage to versions and models beyond what is held physically.
Which phone models and Android versions will you test on?
The list comes from your own analytics and your staff's handsets rather than a generic assumption, agreed with you before testing starts so effort goes to what your customers actually carry.
Can you test a hybrid or cross-platform app the same way?
Yes. Apps built with React Native, Flutter or similar frameworks are tested the same way as fully native ones, since the failure points — permissions, offline behaviour, interruptions — are about the device and operating system, not the framework underneath.
What drives the cost of web and mobile testing?
How many browsers and operating system versions are in scope, whether real devices or a device cloud are required, how many journeys need coverage on each platform, and how much of the testing is automated versus run manually.
What decides how long web and mobile testing takes?
The number of platform and version combinations, how many defects the first pass finds, how quickly fixes reach the test build, and whether app-store review cycles are part of the timeline for mobile releases.
Do you need our app-store or developer account access?
Only where a release build must be distributed for testing through that channel, such as a closed testing track. For most of the cycle, a build installed directly onto test devices is enough and no store access is required.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private