Home/Work/Visit Saudi · Saudi Tourism Authority
CASE 07 · PWC · SAUDI TOURISM AUTHORITY · VISIT SAUDI

Visit Saudi QA automation case study: a national platform tested continuously.

Visit Saudi is the Saudi Tourism Authority's national tourism platform, and its QA automation was built by Aldenebai's founder, Paul Rahme, as Senior QA Automation Engineer through Eurisko, on the PwC-managed programme for the Saudi Tourism Authority, in 2024 to 2025. It put two layers of automated tests around the platform: BrowserStack low-code suites and WebdriverIO end-to-end tests over the public user journeys, API and integration tests underneath them, all wired into CI so regression ran on every build rather than before each release.

E2E BrowserStack + WebdriverIO API integration suites under the UI CI regression on every build
ENGAGEMENT
Saudi Tourism Authority — QA through Eurisko, PwC programme management — Visit Saudi, the national tourism platform
ROLE
Senior QA Automation Engineer
SYSTEM
AI test automation, the QA foundation it stands on
STACK
BrowserStack (low-code) · WebdriverIO · API and integration testing · CI
PERIOD
2024–2025 · KSA
STATUS
Engagement complete

QA on Visit Saudi before the automation

A national tourism platform is public, busy, and never finished. Content changes, campaigns launch, features ship, and any of it can break a journey a visitor is in the middle of: finding a destination, planning a trip, reading about an event. Testing that by hand means clicking through the same journeys on the same browsers and devices before every release, then again when a fix lands. Regression becomes the slowest step in the pipeline, and the first one cut when a deadline is close. The defects that reach production are the ones nobody had time to re-check.

The test automation Paul Rahme built for Visit Saudi

Two layers of automation, and a CI pipeline to run them. The first layer is end to end. BrowserStack low-code suites cover the core public journeys, for broad browser and device coverage that stays quick to maintain. WebdriverIO end-to-end tests, written in code, take the flows that need real logic and assertions a recorder cannot express. The second layer sits underneath the UI. API and integration tests run against the services the platform depends on, so a broken contract or a failing dependency is caught in seconds, at the layer where it happened, instead of surfacing later as a vague UI failure. Both layers run in CI on every build, and a red run names the journey, the step, and the response that failed.

What the team did once the suites ran

Regression stopped being a calendar event. The suites run on every build, so the team reviews failures instead of hunting for them, and a release decision rests on a green run rather than on whoever had time to click through. The same discipline, with LLMs added to generate the tests and heal their own failures, is what Aldenebai now ships as AI test automation.

What the engagement delivered

Every build
regression runs in CI, not on a release calendar
Two layers
end-to-end over the UI, API and integration tests beneath it
Real
browsers and devices covered on every run through BrowserStack suites built as a service

Qualitative results from delivery work; no production metrics are published for this engagement.

Book the Automation Audit

Is your launch date protected by a suite that runs itself?
30 minutes, free. The map names the flows worth covering before the date, and the ones that can wait.
Book the Automation Audit →

The receipt

Illustration of the system's output, not a production screen
Illustration: a cross-browser and device matrix for a nightly run, all passing, one retried

What people ask about QA automation for a national tourism platform

What does QA automation for a national tourism platform actually cover?

The public journeys first, tested end to end on the browsers and devices real visitors use. Then the services behind those pages, through API and integration tests that check contracts and data rather than pixels. Everything runs in CI, so coverage grows with the platform instead of trailing it.

Why use both BrowserStack and WebdriverIO for end-to-end testing?

They solve different problems. BrowserStack low-code suites are fast to build, run across a wide grid of browsers and devices, and maintainable by people who do not write code daily. WebdriverIO end-to-end tests written in code handle the flows that need real logic: data setup, conditional steps, and assertions a recorder cannot express. Using both keeps the broad coverage cheap and the deep coverage precise.

How does API and integration testing at scale fit under the UI tests?

UI tests tell you a journey broke; API tests tell you why, and much faster. Integration suites against the platform's services on every build catch a bad contract or a failing dependency in seconds, at the layer where it happened. The end-to-end layer then only has to prove the pages work when the services do, which keeps it smaller and steadier.

How does this project relate to Aldenebai's AI test automation system?

It is the foundation. The Visit Saudi work was pre-AI: engineers wrote the suites and CI ran them. Aldenebai's AI test automation system keeps that discipline and adds the machine: it reads the product and the code changes, generates the tests, runs them on a schedule, heals its own failures, and reports. At the marina-software client that removed about 80% of manual QA effort.

Bring the platform that has to hold up on launch day.

The free Automation Audit writes its first page: 30 minutes, remote, and a written Automation Map within 48 hours.

Audit: free, 30 min →