Mobile Test Automation on Transformation and SaaS Device Farm Integration Service

Yıldız Tech is the digital innovation and R&D center of Yıldız Holding, designated as an On-Site R&D Center. It builds technology for Yıldız Holding brands and external companies, with a focus on e-commerce. Two brands anchored this project. İstegelsin is Türkiye's first fully online supermarket. Şok is a retailer with 9,500+ stores, 31 warehouses, and 40,000+ employees, with mobile shopping running on the Cepte Şok app.

Yıldız Tech runs many projects in parallel. Testing them was fully manual, and the team had no existing test automation projects. Release cycles were slowed by manual regression, and there was no shared infrastructure to make testing faster or more stable.

Yıldız Tech needed a test automation infrastructure built from scratch. The first scope covered İstegelsin: four projects (Web, Android, iOS, API) on a 6-month roadmap. Once mature, the same setup would extend to the internal Cepte Şok applications.

Two constraints shaped the toolset decision:

• The stack had to cover everything İstegelsin needed and stay tailor-made to their applications.
• The internal Yıldız Tech test team, including members who had never written automation tests, had to adapt and contribute quickly.

Architecture

We ran POCs across language and framework combinations, then locked the stack per project:

• Web: Ruby + Capybara
• Android: Ruby + Appium
• iOS: Ruby + Appium
• API: Java + Karate

Methodology

We ran Scrum with 2-week sprints, tracked work on a Jira board, and held daily meetings, groomings, sprint reviews, and retrospectives. We started with smoke test cases, defined together with the internal team. Smoke cases cover core business functionality and, once built, produce a strengthened project structure, reusable functions, data and reporting integration points, and shared coding conventions.

Development

We built test architectures for Web, Android, iOS, and API, with defined standards for Cucumber test writing, variables, and tag naming. We used a BDD approach so test steps read as plain English and stay readable outside the dev team. The architectures run as a distributed system, executing tests in parallel across browser and device instances. To cut repetitive code, we built a private Ruby gem that generates test data (user info, cart, payment) dynamically at runtime, covering 150+ test data needs. We ran onboarding sessions (web element inspection, Git, Ruby, Capybara, Karate, Appium) and documented everything on Confluence.

CI/CD

Once coverage passed the 30% threshold, we built Jenkins pipeline architecture for Web and API projects, able to run Smoke, Regression, Production, or feature-specific suites. Test-environment builds trigger automatically and report results to a dedicated Slack channel. Smoke cases run every morning. Production cases run daily after deployment. We added the whole project team to the report groups, so every stakeholder sees results and broken features get tracked down faster.

Mobile Device Farm

We handled two integrations in parallel:

• Dynamic app management: we connected Bitrise so apps download and install automatically by specific or last successful build version.
• Device farm: after multiple POCs, the client chose the digital.ai Continuous Testing platform, which let us bring mobile projects into the CI/CD pipeline.
  
  

Load Tests

After UI and API progress, we built load test scripts with Karate + Gatling, generated the required data dynamically, and set up an architecture the whole team can run.

One year of work delivered across the company:

• 3 API test automation projects
• 3 Android test automation projects
• 2 Web test automation projects
• 2 data management projects
• 1 iOS test automation project

Measurable outcomes:

• 80% average test case automation coverage per project
• 1,200+ test cases covered
• 30+ pipeline scripts by test type
• Custom data gem covering 150+ test data needs
• Parallel architecture cuts 2-3 day test runs down to a maximum of 2 hours
• 300+ builds per month through scheduled and triggered runs