How to test a travel booking app
Direct answer
Shipped untested, a travel booking app sells a flight as merchant of record and leaves the traveller's refund waiting when the airline cancels and holds the fare, and adds resort fees after the nightly rate next to scarcity banners that do not match supplier data. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with integration tests: a cancellation or schedule change from a supplier that never reaches the traveller's booking leaves no refund case to test.
9 mandatory testsfirst: integration tests
What counts as a travel booking app
A travel booking app here is a site and app on web, iOS and Android that sells flights, hotels or packages from outside suppliers, often as merchant of record, and handles supplier cancellations, schedule changes and refunds. It covers search and ranking, scarcity messages, fee display, the fare calendar and seat picker, payment, trip pages opened by booking reference and stored passport details. A single hotel's or airline's own booking engine and event tickets sold at a fixed onsale time are out of scope.
Adjacent product types not covered here
- event ticketing platform: An event ticketing platform sells seats for one onsale minute through a queue, so bots and onsale crowds replace supplier cancellations and hotel ranking disclosure.
- ride-hailing app: A ride-hailing app dispatches a driver in real time and charges after the trip, so rider safety and fare changes replace supplier refunds and passport data.
- online marketplace: An online marketplace sells goods from third-party sellers who ship them, so seller verification and payout holds replace supplier schedule changes and passenger transport accessibility rules.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Money leaves or fails to arrive money-loss | money | primary | The airline cancels a flight sold by the app as merchant of record, the airline holds the fare, and the traveller's refund waits on a transfer the app never chases. | |
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | A flight or rail booking flow whose seat picker and fare calendar a screen reader cannot use falls under EU passenger transport accessibility rules. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | Hotel results ranked by commission, 'only 1 room left' banners and resort fees added after the nightly rate drew regulator action against booking sites. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | A booking reference and surname are enough to open a trip, so a guessable lookup exposes passport numbers and travel dates. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | Store review books a test stay; a crash when the supplier returns no availability for the reviewer's dates blocks the release. |
Mandatory tests (9)
Step 1: release smoke tests
Why:store-rejection
Done when: On the release build, a traveller searches, books a test hotel and a test flight, pays and receives both confirmations.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: integration tests
Why:money-loss
Done when: A cancellation or schedule change sent by each connected supplier appears on the traveller's booking and opens a refund case.
Tool class: API client. Who usually runs it: developer.
Step 3: payment and money-flow testing
Why:money-loss
Done when: A test flight cancelled by the supplier sandbox produces a refund to the original test card, shown on the traveller's trip page.
Tool class: API client. Who usually runs it: QA engineer.
Step 4: compliance checks
Why:regulatory-penaltystore-rejection
Done when: A signed checklist shows how results are ranked is disclosed, scarcity banners match supplier data, and store privacy labels match the data collected.
Tool class: test management. Who usually runs it: product manager.
Step 5: end-to-end functional tests
Done when: The first nightly price shown for a hotel equals the checkout total with all mandatory fees for the same dates.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 6: accessibility testing
Done when: A screen reader user picks dates on the fare calendar, chooses a seat and pays for a test flight without help.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 7: security scanning
Why:data-breach
Done when: The scan report for the apps and booking API lists no open high-severity finding on the trip lookup by booking reference or on stored passport details.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 8: penetration testing
Why:data-breach
Done when: The tester's report states they could not open another traveller's trip or passport details by guessing or changing a booking reference.
Tool class: proxy. Who usually runs it: security specialist.
Step 9: device and browser compatibility
Why:store-rejection
Done when: Search, booking and the trip page work on the oldest and newest supported iOS and Android versions, including dates where the supplier returns no availability.
Tool class: device cloud. Who usually runs it: QA engineer.
Recommended and optional tests
contract testsrecommended
Becomes mandatory when a supplier changes its booking API and bookings fail or show wrong details.
localization testingrecommended
Becomes mandatory when the app charges in more than one currency.
data integrity and migration testingrecommended
Becomes mandatory when travellers receive confirmations with the wrong flight time or date.
resilience and failure testingrecommended
Becomes mandatory when a supplier outage stops travellers from searching or leaves bookings charged without a confirmation.
unit testsoptional
May help when fees vary by supplier or country.
regression suiteoptional
May help keep fee display and refund fixes from regressing.
exploratory testingoptional
May help find booking-change states the scripted cases miss.
performance and load testingoptional
May help before fare sales or holiday peaks.
Not needed and why
Not needed: fee and ranking disclosures are covered by the end-to-end and compliance tests. Becomes recommended when checkout abandonment data points to confusion.
offline and poor-network testing
Not needed: booking needs a live supplier price, so there is no offline purchase. Becomes recommended when the trip page or boarding passes must open without signal.
analytics and event tracking tests
Not needed: bookings and refunds come from the booking ledger. Becomes recommended when analytics events drive ranking or pricing.
Order of work
First release
- release smoke tests: On the store build, search, book a test hotel and a test flight, pay and confirm both confirmations arrive.
- integration tests: Send a cancellation and a schedule change from each connected supplier sandbox and confirm each appears on the traveller's booking and opens a refund case.
- payment and money-flow testing: Cancel a test flight in the supplier sandbox and confirm the refund reaches the original test card and shows on the trip page.
- compliance checks: Check that hotel ranking is disclosed, scarcity banners match supplier data and store privacy labels match the data collected, then sign the checklist.
- end-to-end functional tests: For the same hotel and dates, compare the first nightly price shown with the checkout total including all mandatory fees.
- accessibility testing: Have a screen reader user pick dates on the fare calendar, choose a seat and pay for a test flight without help.
- security scanning: Scan the apps and booking API, with the trip lookup by booking reference and stored passport details in scope.
- penetration testing: Have a tester guess and change booking references to try to open another traveller's trip and passport details.
- device and browser compatibility: Run search, booking and the trip page on the oldest and newest supported iOS and Android versions, including dates where the supplier returns no availability.
Ongoing cadence
- release smoke tests: On every store build before submission.
- integration tests: When a supplier is added or changes its API version.
- payment and money-flow testing: After each change to refund handling or merchant of record terms.
- compliance checks: After each change to ranking, scarcity messages or fee display.
- end-to-end functional tests: After each change to hotel fee rules or the checkout screen.
- localization testing: When the app starts charging in a second currency.
- contract tests: When a supplier changes its booking API and bookings fail or show wrong details, then before each release.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of travel booking app (web, ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
localization testing
- Lokalise QATranslation management with in-context review. webiosandroidcommercial
- Pseudolocalization (Android, iOS)Built-in pseudolocales to find truncation and hard-coded strings. iosandroidopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for travel booking app has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the travel booking app is accepted when a cancellation or schedule change from each connected supplier appears on the traveller's booking and opens a refund case, and a supplier-cancelled test flight is refunded to the original card. The first nightly price shown for a hotel equals the checkout total with all mandatory fees for the same dates. Another traveller's trip and passport details cannot be opened by guessing or changing a booking reference.
Brief
# Test brief: travel booking app Product type: travel booking app. Flights, hotels or packages with supplier integrations and cancellations. Risk map and evidence: https://howtotestaproduct.com/how-to-test/travel-booking/ Printable checklist: https://howtotestaproduct.com/checklists/travel-booking/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer. Done when: On the release build, a traveller searches, books a test hotel and a test flight, pays and receives both confirmations. 2. integration tests (risks: money-loss). Tool class: API client. Usually run by: developer. Done when: A cancellation or schedule change sent by each connected supplier appears on the traveller's booking and opens a refund case. 3. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer. Done when: A test flight cancelled by the supplier sandbox produces a refund to the original test card, shown on the traveller's trip page. 4. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager. Done when: A signed checklist shows how results are ranked is disclosed, scarcity banners match supplier data, and store privacy labels match the data collected. 5. end-to-end functional tests (risks: regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer. Done when: The first nightly price shown for a hotel equals the checkout total with all mandatory fees for the same dates. 6. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen reader user picks dates on the fare calendar, chooses a seat and pays for a test flight without help. 7. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan report for the apps and booking API lists no open high-severity finding on the trip lookup by booking reference or on stored passport details. 8. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist. Done when: The tester's report states they could not open another traveller's trip or passport details by guessing or changing a booking reference. 9. device and browser compatibility (risks: store-rejection). Tool class: device cloud. Usually run by: QA engineer. Done when: Search, booking and the trip page work on the oldest and newest supported iOS and Android versions, including dates where the supplier returns no availability. Acceptance criteria wording: A release of the travel booking app is accepted when a cancellation or schedule change from each connected supplier appears on the traveller's booking and opens a refund case, and a supplier-cancelled test flight is refunded to the original card. The first nightly price shown for a hotel equals the checkout total with all mandatory fees for the same dates. Another traveller's trip and passport details cannot be opened by guessing or changing a booking reference. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a travel booking app
What testing does a travel booking app need?
9 tests are mandatory, starting with a booking smoke test and integration tests of supplier cancellations and schedule changes. Each is tied to one of the 5 risks in the map, such as refunds held by the airline, fees added after the nightly rate and trips opened with a guessed booking reference. Contract, localization, data integrity and resilience tests are recommended, each with the event that makes it mandatory.
What gets a travel booking app rejected by an app store?
The map marks store rejection as a by design analysis risk: store review books a test stay, and a crash when the supplier returns no availability for the reviewer's dates blocks the release. The booking smoke test runs on every store build, and compatibility tests run search, booking and the trip page on the oldest and newest supported iOS and Android versions.
What does GDPR mean for testing a travel booking app?
The map cites the General Data Protection Regulation for the data breach risk. A booking reference and surname open a trip, so a guessable lookup exposes passport numbers and travel dates, and penetration testing guesses and changes booking references to check that it cannot.
How should checkout be tested in a travel booking app?
Compare the first nightly price shown for a hotel with the checkout total including all mandatory fees for the same dates. Then cancel a test flight in the supplier sandbox and confirm the refund reaches the original card, and have a screen reader user book a test flight through the fare calendar and seat picker.
Which tests in a vendor test plan for a travel booking app are not needed?
Usability testing is not needed while fee and ranking disclosures are covered by end-to-end and compliance tests, until checkout abandonment data points to confusion. Offline testing is not needed while booking needs a live supplier price, until the trip page or boarding passes must open without signal. Analytics tracking is not needed until analytics events drive ranking or pricing.
Evidence
ev-0186regulatorprimary
14 CFR 260.6: Refunds for Airline Fare and Ancillary Service Fees (cancelled, delayed or changed flights), U.S. Department of Transportation (14 CFR Part 260, text via Cornell Legal Information Institute)
Federal refund rule for cancelled or significantly changed flights: when a ticket agent is the merchant of record, the airline must tell the agent the traveller's refund eligibility and transfer the funds so the agent can refund. Supports money-loss for a travel booking app that sells flights.
published undated · verified 2026-10-07
ev-0016standardprimary
Web Content Accessibility Guidelines (WCAG) 2.2, W3C
WCAG 2.2 is the W3C standard that accessibility law and procurement rules reference; level AA is the usual target.
published undated · verified 2026-10-07
ev-0047regulatorprimary
European Accessibility Act, European Commission
The Commission's page lists e-commerce and services related to air, bus, rail and waterborne passenger transport among the services the Act covers. Transfers to an online auction platform selling to EU consumers (e-commerce) and to a travel booking app selling transport (passenger transport services).
published undated · verified 2026-10-07
ev-0179regulatorprimary
16 CFR 464.1: Definitions (Rule on Unfair or Deceptive Fees), Federal Trade Commission (16 CFR Part 464, text via Cornell Legal Information Institute)
The federal fee rule names live-event tickets and short-term lodging as the covered goods, and its section 464.2 requires the total price to be shown with any advertised price. Applies to an event ticketing platform and to a travel booking app that sells hotel stays.
published undated · verified 2026-10-07
ev-0187regulatorprimary
Online hotel booking, Competition and Markets Authority
UK enforcement case that ended with formal undertakings from hotel booking sites on search ranking influenced by commission, pressure selling about room availability, misleading discount claims and fees added after the first price. Supports regulatory-penalty for a travel booking app.
published undated · verified 2026-10-07
ev-0012standardprimary
OWASP API Security Top 10 2023, OWASP Foundation
The API Security Top 10 names API-specific failures such as broken object level authorization and unrestricted resource consumption.
published undated · verified 2026-10-07
ev-0025regulatorprimary
Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union
The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.
published undated · verified 2026-10-07
ev-0001store-guidelineprimary
App Review Guidelines, Apple
Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).
published undated · verified 2026-10-07
ev-0002store-guidelineprimary
Developer Program Policy, Google Play
Google Play applies these policies to every Android app it distributes and can reject, suspend or remove apps that violate them.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.