Use Case in Software Testing: How to Turn One Into Test Cases
Every path through a use case becomes at least one test case. A worked bank-transfer example shows the test table, and ISTQB's 2023 and 2025 syllabus changes explain…
Airline and Travel Software Testing Services
Vervali tests airline and travel platforms end to end: booking engines and passenger service system integrations, check-in and boarding, loyalty and fare rules, payments and refunds, schedule-change and disruption handling, mobile applications, and behaviour under a sale or an irregular-operations spike. A major airline's booking and check-in platform reached 85% test coverage and 70% fewer customer-reported issues within two release cycles with our team.
150+ clients
450+ projects
275+ engineers
15+ years
ISO/IEC 17025:2017Accredited testing laboratory
CMMI Maturity Level 3The process is written down and repeats
ISO 9001:2015Quality management
ISO/IEC 27001Information security
Where Airline and Travel Platforms Break
Four failure points that turn into lost bookings, stranded passengers or a regulator's letter.
Slow Hosts, Not Down Hosts
Bookings that pass a happy-path script and fail when the passenger service system is slow, halfway through payment.
Systems That Disagree
Check-in, bag tags, status pages and the app telling different stories while a flight is delayed or cancelled.
Refunds That Break Later
Refunds, vouchers and change fees that fail months after the cancellation, long after the release went green.
Accessibility Gaps
Airline websites and apps that miss WCAG 2.0 AA, which 14 CFR 382.43 has required since 2015.
Find the booking failures before your passengers do.
Free Booking-Flow TestBooking Engines and Passenger Service System Integrations
A defect here is a booking that never completes and a customer who books elsewhere.
What Is Tested in a Booking Flow
Availability and pricing consistency between the engine and the passenger service system, seat and ancillary selection, hold and timeout behaviour, currency and tax, and the failure cases when the upstream system is slow rather than down. Those paths get the same functional and regression discipline as our application testing, tuned to airline and travel platforms.
The Integration Surface
The messages, the timeouts, the tax and currency rules, and what the passenger sees when the host disagrees with the web. That surface is your actual GDS, PSS, inventory and payment stack. After NDA we name those systems in the design, and if we have not tested that host before, we say so before we quote.
A Failed Booking Is a Lost Passenger
The passenger books with the competitor that still answered. Coverage on this path is the first thing we price, not an add-on after the happy path is green. We also test a fare that disappears between search and confirm, and a hold that expires mid-form.
Check-In, Boarding and Disruption Handling
Disruption is where airline software actually fails, and it is testable.
Check-In and Boarding
Online and mobile check-in, seat changes, baggage, boarding pass delivery and scanning. The airline engagement covered check-in. Disruption and rebooking go into your design whenever they are the risk, with the expected result agreed with your operations owner before execution.
When the Flight Changes
A flight delayed, cancelled or reallocated, and every downstream system having to agree. The test is whether check-in, inventory, bag tags, status pages and the app still tell the same story when the host is slow, when a passenger is already at the airport, and when the call centre is taking the same request.
Loyalty, Fare Rules and Ancillary Revenue
The highest-margin flows are also the most rule-dense, so this is where regression pays most.
Accrual, Tiers and Ancillaries
Points accrual and redemption, tier logic and its edge cases, fare rules and change or cancel penalties, and ancillaries such as bags, seats and insurance. If loyalty is not in your first release, we still name it as a gap rather than pretend the happy path is the product.
Rules Without a Spec
We reconstruct the intended rule with your revenue owner when there is no spec, then test the failure cases: a tier that almost qualifies, a redemption that expires mid-booking, a change fee that should not apply after a schedule change you caused. Offers that no longer sell are retired so you are not paying to retest them.
Payments, Refunds and PCI DSS
A passenger who cannot pay is loud. A passenger who paid twice writes to a regulator months later.
Payment and Refund Paths
Multi-currency payment, split and partial payment, vouchers, and the refund path, which is slower to notice and more expensive to get wrong than the payment path. Refunds and vouchers after a cancellation sit in the functional suite from the first release.
PCI DSS Scope
PCI DSS scope for a travel platform is the cardholder data you touch, what is tokenised, and the scripts on the payment page. We test those controls. Application and API attack work is scoped separately as security testing of agreed in-scope assets, and control-by-control evidence comes through our compliance testing.
Your next sale should not be the first real load test.
Talk to Our QA LeadPeak Load: Sales, Schedule Changes and Irregular Operations
Three load shapes, each modelled on its own in our performance testing. The airline engagement delivered 40% faster page loads once the slow paths were in the suite.
A Sale
Predictable and concentrated. Model it from last year's own traffic, with the fare that will actually run, and the checkout path loaded, not only search. Search that stays up while payment dies is a failed sale, not a green report.
A Schedule Change
Unpredictable. It hits servicing rather than booking: reissue, notify, rebook. Test that path, not a second sale script. The host is busy and the passenger is already ticketed. Those are different bottlenecks.
Irregular Operations
Everything at once, while call centre volume spikes. The test is whether check-in, rebooking and status still agree when the host is slow. Model it from a real irregular-operations day, not from a round number of virtual users.
Accessibility, Including the US Department of Transportation Rule
For airline websites this is a legal obligation with a date attached, not a quality argument.
What 14 CFR 382.43 Requires
Air carriers that operate at least one aircraft with more than 60 seats, and that own or control a primary website marketing air transportation to the general public in the United States, must make public-facing pages conform to WCAG 2.0 Level AA. Core services (booking, check-in, itinerary, status, frequent flyer, schedules, contact) had to conform by 12 December 2015; remaining pages by 12 December 2016.
Where ADA Still Applies
ADA still matters for agencies, hotels and sites that are not the primary carrier website. We test with keyboard and a screen reader against WCAG 2.0 AA where 382.43 applies, and against the version your other buyers named, and we map which rule binds you in the design. Full audits, VPAT support and Title II guidance run through our ADA and Section 508 compliance testing.
Mobile Applications
The airline app is its own surface. A web booking that works does not prove the app.
Travel-Specific Journeys
Offline boarding passes, push tied to disruption, deep links from email into the app, and wallet integration. A passenger who only ever checks in on a phone will never see the desktop pass you tested, so core flows named in 382.43 are tested in the app whenever a passenger completes them there.
Device and Version Coverage
Device and version coverage follows our mobile application testing matrix, applied to these travel journeys. If a device is not in the lab, we say so in the design before we quote, rather than promising a matrix we cannot run.
Case Study
How a major airline cut customer-reported issues within two release cycles.
Major airline · booking and check-in
Before: coverage on the booking and check-in platform was too thin for the release pace, customers reported issues testing had not seen, and pages were slow on the paths that sell seats. Vervali built a functional and regression suite around those paths, with automation on the stable journeys that sell seats and get passengers to the gate, and load on the servicing that was actually slow. Disruption experiments and one-off fare trials stayed manual. After two release cycles: 85% test coverage, 70% fewer customer-reported issues, and 40% faster page loads, with a regression suite running before every release.
85% test coverage 70% fewer customer-reported issues 40% faster page loads Two release cyclesHow an Engagement Starts
From a first look at one booking flow to a suite that keeps pace with your releases, 9am to 1pm Eastern with delivery from India.
-
01
Share the Platform
Tell us the products in play (web, mobile, PSS, payments) and the paths that take money or fail a disruption, with staging access under NDA.
-
02
Get the Coverage Model
A first assessment is quoted after that look: the coverage model, the manual and automated split, and the load shapes that apply to your platform.
-
03
Start With One Booking Flow
A free test of one booking flow is the fastest first look at defect quality and cadence. If you already know the platform, a QA lead scopes the full engagement.
-
04
Keep It Current, Build What's Next
We keep the suite current as fares, apps and hosts change. Development comes second: the same team can build or extend booking, check-in, loyalty and servicing features through our development services, with testing inside every sprint.
Frequently Asked Questions
Three load shapes, not one spike. A sale is modelled from your own last peak, with checkout loaded. A schedule change hits servicing. Irregular operations hit everything while the host is slow. Each shape gets its own performance test model. The airline case included 40% faster page loads after those paths were in the suite. A free test of one booking flow is functional first; load is quoted from the shape you actually get.
Yes. Web booking and servicing, and the airline or travel app: offline boarding passes, disruption push, deep links and wallet. Device and version coverage follows our mobile testing matrix. Core flows that 14 CFR 382.43 names are tested on both surfaces when the passenger can complete them there. A web pass does not prove the app.
We test the integration surface you actually run: availability, pricing, holds, tax, timeouts and what the passenger sees when the host is slow. Systems are named in the design after NDA, not as a public logo list. If we have not tested that host before, we say so before we quote rather than gesture at a catalogue. That is the honest answer until Vervali publishes a named list we can evidence.
We test payments, refunds and PCI DSS scope as controls on the travel path: the cardholder data you touch, what is tokenised and the scripts on the payment page. Application and API attack work is scoped separately as security and penetration testing of agreed assets, under ISO/IEC 27001 controls. Refunds sit in the functional suite because they fail later and cost more than a declined card.
As their own flows, not as a second booking script. Schedule change is reissue, notify and rebook when the host disagrees. Irregular operations is those paths plus check-in and status while everything is slow. We write the expected result with your operations owner before execution, because a fail here is a passenger stranded, not a ticket in Jira.
Yes, on stable booking, check-in and servicing paths that run every release. Disruption experiments and fare trials that change every sprint stay manual. The airline case used automation on the journeys that sell seats. Tooling and payback are agreed up front, and you get the manual and automated split before the quote, not after months of brittle scripts.
If you are a US or foreign air carrier operating at least one aircraft with more than 60 seats, and you own or control a primary website that markets air transportation to the general public in the United States, 14 CFR 382.43 requires WCAG 2.0 Level AA. Core services had dates in 2015 and 2016. Other travel sites may still have ADA exposure. We map which rule binds you in the design.
Accrual, redemption, tier edges, change and cancel penalties, bags, seats and insurance. These are rule-dense, so regression pays. We reconstruct the intended rule with your revenue owner when there is no spec, then test the failure cases, not only the member who always qualifies. That regression suite becomes an asset. Offers that no longer sell are retired so you are not paying to retest them.
Email Us
Call Us
