Thaat is a consumer service-booking app targeting the Saudi Arabian market. Its client, based in Dubai, UAE, hired Testers-HUB to provide independent QA across real iOS and Android devices.
The engagement focused on the customer’s route into the app: signup, login, OTP verification, social authentication, profile setup, the Home screen and order creation. Testing identified 100+ defects and 20 improvement suggestions within the completed scope.
The client’s challenge
The client needed to validate account and booking journeys across different devices before release. These flows are closely connected: a problem with registration, account linking or verification can prevent a customer from reaching the service-booking experience.
The QA requirement was therefore more specific than checking whether screens opened. The client needed independent validation of the agreed journeys on both platforms, investigation of unexpected behaviour and findings that the development team could act on. Testers-HUB supplied that cross-device testing support.
Engagement at a glance
- Product: Thaat, a consumer service-booking app.
- Client location: Dubai, UAE.
- Target market: Saudi Arabia.
- Platforms: iOS and Android.
- Physical devices: eight—four iPhones and four Android phones.
- Reported findings: 100+ defects and 20 improvement suggestions.
This was a project-specific device matrix, not a standard package entitlement. The eight-device engagement should not be confused with the 2–4 selected devices included in Testers-HUB’s fixed mobile packages.
The real-device test matrix
The confirmed matrix included newer flagship devices, mid-range Android hardware and older-generation iPhones. The OS versions below are the project-reported versions; patch or build identifiers beyond those supplied are not implied.
| Platform | Device | OS version |
|---|---|---|
| iOS | iPhone 17 Pro | iOS 26 |
| iOS | iPhone 15 | iOS 26 |
| iOS | iPhone 13 | iOS 18.3.2 |
| iOS | iPhone 11 | iOS 17.7 |
| Android | Samsung Galaxy S25 Ultra | Android 16 |
| Android | Google Pixel 8 | Android 16 |
| Android | Samsung Galaxy A52 | Android 14 |
| Android | Samsung Galaxy A22 | Android 13 |
Testing across this matrix provided multiple environments for checking the scoped journeys. It does not mean every reported defect occurred on all eight devices, and no device-specific defect attribution is made without the corresponding evidence.
How Testers-HUB approached the QA work
1. Follow the customer’s entry journey
The scope covered signup and login through OTP and social authentication, followed by profile setup, Home and order creation. These were treated as connected customer journeys rather than unrelated screens.
2. Combine functional checks with exploratory testing
Functional testing checked the scoped behaviour, while exploratory work investigated unexpected states around account creation, authentication and network handling. The confirmed findings included areas where a customer’s account state or verification journey required closer attention.
3. Review behaviour across the device matrix
Real-device execution covered both iOS and Android. Cross-device QA helped the team examine the consumer experience across different hardware and OS versions; the public summary does not claim exhaustive coverage of every possible device or account state.
4. Separate defects from improvement suggestions
The engagement identified 100+ defects and 20 improvement suggestions. Keeping those categories separate gives the client a clearer distinction between reported problems and proposed refinements. The findings formed the basis for development follow-up rather than a blanket claim that the app was ready to release.
Key finding areas
The following are confirmed areas from the project, not additional defects added to the total. Detailed reproduction steps, personal data and client-internal evidence are not reproduced here.
- Account linking: issues in the relationship between authentication and the customer’s account required investigation. Correct account association matters before customers continue into profile and ordering workflows.
- Duplicate registration: registration behaviour raised duplicate-account concerns. This matters because repeated registration should not leave the customer or product team uncertain about which account is being used.
- Social signup: findings concerned the social-authentication entry path. That path needs validation as part of the complete customer journey, not merely as a successful response from a login provider.
- OTP and network handling: findings concerned verification and behaviour under network-related conditions. Clear state and recovery behaviour are important when customers are trying to complete account access.
These are practical examples of why mobile app testing services need to cover account states and connected workflows as well as visible screens.
Reporting, coordination and the retesting boundary
The reported outcome is the identification of 100+ defects and 20 improvement suggestions for client review and development follow-up. Fix completion and completed retesting have not been confirmed for this public case study. We therefore do not describe the issues as resolved or claim a defect-free launch, conversion increase or financial saving.
For a follow-up QA cycle, the appropriate next step is to verify reported fixes on the relevant build and device, then agree regression coverage around connected journeys. That is a proposed next step—not a claim that it has already happened in this engagement.
What this engagement shows a prospective buyer
A consumer app’s release risk can sit in the transitions between registration, authentication, profile setup and ordering. Thaat’s engagement demonstrates a defined iOS and Android testing scope, a confirmed real-device matrix and a distinction between defects and improvement suggestions.
If your team needs external execution capacity, review how to hire mobile app testers. For budget planning, compare the scope and exclusions in our mobile app testing cost guide; a custom device matrix or additional cycles must be agreed separately.
Need multi-device QA before your next release?
Need your iOS and Android app tested across multiple real devices before release? Share your build, priority workflows and target devices with our QA team. We’ll recommend the coverage, tester allocation and effort for your scope.
Need QA testing support for a similar release?
Tell us about your app, website, game, platform coverage, and launch timeline. Testers HUB will recommend a practical QA scope and quote.