What was tested?
| Testing area | Coverage |
|---|---|
| Devices | Samsung, Realme, Motorola, OnePlus, Samsung S9 Tablet |
| Android versions | Android 10 – Android 16 |
| Orientation | Portrait and landscape |
| UI testing | Prayer interface, bottom section, language options, legal information |
| Functional testing | Prayer times, countdown, Qibla, settings, language and legal options |
| Stability testing | Navigation, scrolling, orientation changes |
| Scenarios (8) | Prayer Dashboard, Prayer Countdown, Zeitgeber, Qibla, Bottom Section, Privacy Information, Landscape Mode, Offline Experience |
| QA findings | 3 issues + 2 enhancement suggestions |
- 1
The Developer's Problem
The developer had already tried to complete Google Play's closed testing process twice independently, but both attempts were unsuccessful. After two failed attempts, the challenge was no longer simply finding testers — it was understanding how to approach the testing process in a way that felt reliable and reduced the uncertainty around Google's expectations.
- 2
Starting Situation
Salaaaaat is intentionally minimal. The app focuses on the five daily prayers, live countdowns, prayer-window transitions, a circadian-style view of the solar day, and Qibla direction. It works offline and does not require an account. Because the app is designed around real-time prayer information and a simple, distraction-free interface, testing involved using the actual app rather than treating the closed test as an installation-only exercise.
- 3
The Developer's Concern About External Testing
The developer was initially skeptical about using an external testing service. In particular, they were concerned that Google might consider externally arranged testing suspicious, potentially resulting in rejection or other problems for the app.
That concern was an important part of the engagement. The testing process therefore needed to be handled as an actual testing activity, with testers using the application rather than simply installing it to satisfy a numerical requirement.
- 4
Testing Approach
The managed testing process focused on getting real testers through the app and maintaining the testing activity required for the closed-testing period. The developer specifically described the experience as a real testing process rather than simply having people install the app for the sake of meeting the requirement.
- 5
Issues Identified
Testing on phones from four manufacturers plus a tablet, across Android 10 to 16 and in both portrait and landscape, produced three issues in the QA report. The first is the one the report calls its primary concern:
- Priority: in landscape orientation the page couldn't be scrolled, so content beyond the visible screen was unreachable.
- The language-selection links in the bottom section were partially hidden.
- There was no clearly accessible Privacy Policy link.
- 6
Production Access Guidance
After the 14-day cycle, the developer received a production application guide with suggested answers for each section of Google's questionnaire — about the closed test, the app, and production readiness — plus the extra question Google asks when an earlier application was unsuccessful.
- 7
Outcome
After two previous unsuccessful attempts, the developer reported that Salaaaaat was finally approved after working with Teekam Suthar.
The developer also highlighted that the service removed much of the stress and confusion surrounding the closed testing process and said they would use the service again for another app.
Deliverable
Inside the QA report
Salaaaaat — Comprehensive Android Application Testing & Functional Evaluation
Teekam's QA Team · October 2026 · 8 pages
5
Findings
3
Issues
2
Enhancements
Scenarios tested (8)
- Prayer Dashboard
- Prayer Countdown
- Zeitgeber
- Qibla
- Bottom Section
- Privacy Information
- Landscape Mode
- Offline Experience
Issues found (3)
#1PriorityUI / ResponsivenessLandscape content cannot be scrolled
Screen / flow: Landscape orientation
In landscape, the page didn't scroll, so content beyond the visible viewport was inaccessible.
Recommendation: Enable scrolling in landscape mode so all content stays reachable within the viewport.
#2UI / AccessibilityLanguage links are partially hidden
Screen / flow: Bottom section / language selection
The bottom section's language-selection links were partially hidden and not fully visible.
Recommendation: Adjust the section's layout, spacing or scrolling so all language links and supporting text are fully visible.
#3Legal / UsabilityPrivacy Policy link is missing
Screen / flow: Application information / bottom section
The app didn't provide a clearly accessible Privacy Policy link, reducing transparency about data practices.
Recommendation: Add a clearly visible Privacy Policy link in About, Settings or the bottom information section.
Enhancement suggestions (2)
#4Usability / MaintenanceImplement In-App Updates
Screen / flow: Application updates
Users may stay on outdated versions and miss fixes, performance improvements or new functionality.
Recommendation: Implement Google Play In-App Updates — flexible for routine releases, immediate for critical ones.
#5User engagement / UXAdd In-App Rating and Review
Screen / flow: Settings / App review
An in-app review flow would let users give feedback without leaving for the store listing.
Recommendation: Integrate the Google Play In-App Review API and trigger it at moments that don't interrupt the user.
Report conclusion: The report's primary concern was the lack of scrolling in landscape mode, followed by the partially hidden language links and the missing Privacy Policy link — with in-app updates and in-app reviews suggested to support maintenance and engagement without changing the app's intentionally simple design.
“I had already tried the closed testing process twice on my own and unfortunately failed both times. After that, I decided to give u/teekamsuthar a try. To be honest, I was a bit skeptical at first about using an external service for this. I was worried that Google might consider it suspicious or that my app could get rejected or even banned for using testers this way. But my experience was actually really good. They handled the testing professionally and made sure it was a real testing process, rather than just having people install the app for the sake of meeting the requirement. After my two failed attempts, my app was finally approved with their help. What I appreciated the most was that it took away a lot of the stress and confusion around what Google actually expects during the closed testing process. Based on my experience, I would definitely use their service again if I need to go through this process with another app.”
Evidence
- Google Play listing for Salaaaaat
- Developer testimonial on Reddit, r/testimonials
- Full QA report — 8 pages (PDF)
- Production application guide (available on request)
What this case demonstrates
This engagement is an example of a developer who had already attempted the closed testing process twice before using a managed testing service. The developer's main concern was not simply finding people to install the app, but whether an externally managed testing process could be legitimate and useful. According to the developer, the testing was handled as a real testing process and the app was eventually approved.
The case also demonstrates why a closed test can be treated as more than a tester-count exercise: the developer specifically valued having the process handled professionally and reducing the uncertainty and stress around what Google expected.
Important note
Google Play controls all production access decisions, and outcomes vary by app and developer account. The approval described in this case is the developer's reported outcome after working with the service; it does not guarantee approval for another app or account. This case also reflects the developer's experience and concerns about external testing, not a statement that Google endorses any particular testing service.