Software testing checklist before launch for Saudi apps

A software testing checklist before launch in Saudi Arabia has to cover more than whether features work. Arabic and right-to-left screens, mada and Apple Pay payments, VAT and e-invoice outputs, local phone numbers, Hijri dates and peak traffic all need checking. This guide gives a practical pre-launch checklist for apps and websites aimed at Saudi customers, and explains how to plan the testing so launch day is uneventful.

What should be tested before any launch?

Every critical user journey, end to end, on the devices and browsers your customers use. Start with the paths that make money or create legal records, then work outwards.

• Sign-up, login, password reset and OTP by SMS to Saudi mobile numbers
• The main journey: search, booking, ordering or form submission through to confirmation
• Payments, refunds and failed payment handling
• Emails, SMS and push notifications in the correct language
• Admin and staff functions that support the customer journey
• Reports and exports that finance and management rely on
• Behaviour after updates: existing users, saved data and sessions

Write each journey as a short test case with expected results, so anyone on the team can run it and the result is clear. These cases become your regression suite for every future release.

How do you test Arabic and right-to-left screens?

Run every screen in Arabic on real phones and review it with a fluent Arabic reader. Automated checks catch missing translations, but only people catch awkward wording and layouts that feel wrong.

• No English strings left in Arabic screens, alerts, emails or PDFs
• Layouts mirror correctly, while logos, media controls and phone numbers do not
• Mixed Arabic and Latin text, such as product codes and brand names, displays in the right order
• Long Arabic words and labels do not overflow buttons or get cut off
• Arabic input works in every text field, search box and filter
• Numbers, prices in SAR and dates, including Hijri dates where used, display consistently
• Screen readers announce Arabic content correctly

Test language switching mid-journey too. A customer who switches from English to Arabic at checkout should keep their basket and land on the same step.

How should payments and invoices be tested?

Test every payment method in the gateway's sandbox, including failures and refunds, then run a small number of real transactions in production before opening to everyone. Check that invoices match what your accountant expects.

Cover mada cards, Visa and Mastercard, Apple Pay and any wallets or instalment options you offer. Include cancelled payments, 3-D Secure failures, double clicks on the pay button, slow networks and customers who close the app mid-payment. Confirm the order is marked paid only after the server verifies the gateway's notification.

Invoices need the same care. Check that VAT at 15% is calculated correctly at line and total level, that credit notes link to the original invoice, and that the e-invoicing flow behaves as ZATCA's rules require for your business, including what happens when the connection to ZATCA is unavailable. Your tax adviser should confirm the expected output.

Who should sign off before launch?

The business, not only the testers. User acceptance testing by the people who will run the product day to day confirms it fits real work, and their sign-off makes the launch decision clear.

Ask staff from operations, finance and customer service to run their own scenarios in a staging environment with realistic data. Finance should confirm that payments, refunds and invoices reconcile. Customer service should try the journeys customers will call about. Record their findings in the same defect tracker as the testers, so nothing is lost in email or chat.

Which devices and conditions should you cover?

Cover the iPhone and Android models your customers actually use, a range of screen sizes, and the main browsers for web. Use analytics from your existing site or app to choose, rather than guessing.

Test on mobile data as well as office Wi-Fi, because loading times and timeouts feel very different. Include older phones with less memory, devices set to Arabic as the system language, and large text settings. Check time-related behaviour against Saudi time, and any schedules or service-level rules that depend on the Sunday to Thursday working week.

How do you check performance, security and privacy?

Load test the busiest journeys at the traffic you expect at peak, scan for common security weaknesses, and review how personal data is collected and stored. Each of these is cheaper to fix before launch than after.

Peak periods in Saudi Arabia can be sharp: sales campaigns, payday, Ramadan evenings and back-to-school all bring traffic spikes for different businesses. Load tests should model your own peaks and check database, payment and SMS limits, not only web servers.

• Login and OTP protected against brute force and abuse
• Users cannot see or change other users' data by altering IDs in requests
• Secrets and gateway keys kept out of the app and the code repository
• HTTPS everywhere and secure session handling
• Personal data collected only where needed, with a privacy notice in Arabic and English
• Data handling reviewed against the Saudi Personal Data Protection Law (PDPL) with your legal adviser
• Backups taken and a restore actually tested

What does a realistic launch plan look like?

Plan the release, not just the testing. A staged rollout, monitoring and a rollback plan turn a launch from a gamble into a routine step.

For example, a car rental company releasing a new booking app might first open it to staff, then to a small share of customers in one city, while monitoring bookings, payments and crash reports. Once the numbers look normal and no serious issues appear, it opens the app to everyone and announces it. If something breaks, the team can pause the rollout without affecting most customers.

• Entry and exit criteria agreed: which defects block launch and which can wait
• App store submissions planned with time for review
• Monitoring, crash reporting and alerts live before launch
• Rollback or hotfix plan, with named people on call
• Customer support briefed in Arabic and English on known issues

How is pre-launch testing usually run?

Testing works best as part of delivery rather than a phase squeezed in at the end. It follows the same structure as the build: discovery, written scope, phased releases, testing and handover.

We start with a video-call workshop to understand the product, users and risks, then write a test plan covering journeys, devices, languages and payment cases. A named lead runs testing in two-week sprints alongside development, with a demo every sprint showing what was tested and what was found. Releases are phased, each with regression testing before it ships. At handover, test cases, automation scripts and reports are yours, stored in accounts registered to your company. Our quality assurance service and software testing company page for Saudi Arabia explain more, and we test the mobile apps we build for Saudi Arabia the same way.

Frequently asked questions

How long should pre-launch testing take?

It depends on the size of the product and how much was tested during development. If testing ran every sprint, the final pre-launch pass is short; if it was left to the end, expect a longer cycle and more fixes.

Should we automate tests before launch?

Automate the stable, repeated journeys such as login, checkout and key forms, so every future release is checked quickly. Keep exploratory and Arabic language review manual.

Can our own staff do the testing?

Staff are valuable for acceptance testing because they know the business. A dedicated tester adds structure, device coverage and edge cases that staff tend to skip.

What if we find serious bugs a week before launch?

Use the agreed exit criteria. If a defect affects payments, data or legal records, delay or reduce the launch scope rather than ship it.

If you have a launch coming up and want an independent check, talk to us about a pre-launch test plan.