🩵 Travel & Booking QA

Model answer

I'd test the relationship between the dates, not just each field. Core cases: check-in before check-out (valid), check-out before check-in (rejected), same-day check-in/out per the product rule, and a single-night minimum. Boundaries: today as check-in, a past date rejected, the maximum advance-booking horizon, and a stay longer than the allowed maximum. I'd cover availability for the chosen range — a range that's partially unavailable should surface clearly, not silently shorten. For flights I'd add one-way vs return, and a return date before departure. I'd test month/year rollovers and that the picker and the server agree on the same constraints, since client-only validation can be bypassed. The thread is that a date range is a constrained pair with travel-specific rules, so I test the pair and its domain limits.

Model answer

I'd anchor every case to the itinerary. Departure time must display in the origin's local zone and arrival in the destination's local zone, with the computed duration matching the true elapsed time regardless of the offset between them. Then the hard cases: an overnight flight where arrival is the next calendar day; a westbound trans-Pacific flight crossing the date line where you arrive 'the day before' you left in local terms; and a flight scheduled across a DST transition in either endpoint, where a naive calculation gains or loses an hour and corrupts the duration. I'd test a same-zone flight as the control, and a red-eye near midnight where off-by-one-day bugs surface. I'd verify the stored times are unambiguous (UTC plus zone) and only converted for display. The signal is that this is itinerary time, where 'when and where' are coupled, not a single-clock conversion.

Model answer

A hold is a TTL'd reservation, so I test the full lifecycle. On entering checkout, the seat/room is held and unavailable to others; I confirm a second user can't hold the same unit. On abandonment or timeout, the hold releases and the inventory becomes bookable again — I assert it doesn't stay locked forever, which would be phantom unavailability. On completion, the hold converts to a confirmed booking. The critical race is expiry colliding with payment completion: a payment that finishes just as the hold expires must resolve deterministically — either honour the booking or fail cleanly with the customer's money handled correctly, never charge for a released unit. I'd test extending a hold, re-entering checkout, and concurrent holds on the last unit. The principle is that the hold is a promise with a deadline, and both the keep-the-promise and the deadline-passed paths need explicit, race-safe behaviour.

Model answer

This looks like the e-commerce last-unit race but the twist is that the real inventory lives in an external supplier/GDS with a confirmation round-trip, so it's a distributed race, not a local decrement. I'd fire two concurrent booking requests for the last seat and assert exactly one ends up confirmed, with the other receiving a clean no-availability result. The failure I specifically design for is the platform optimistically confirming both to the user before the supplier has confirmed, then getting one rejected later — so I test the lag: stub the supplier to delay confirmation and assert the platform holds the booking in a pending state rather than promising a seat it doesn't yet have. I'd cover supplier rejection after a local hold, and reconciliation when the supplier's count disagrees with ours. The distinction from local oversell is the external authority and its latency, so the assertion is about not running ahead of the supplier's confirmation.

Model answer

A multi-leg booking is a distributed transaction across suppliers that can't be a single atomic commit, so I test it as a saga with compensation. The headline case: legs 1 and 2 confirm, leg 3 fails. The assertion is that the system compensates — releases or refunds the already-confirmed legs and surfaces a clear failure — so the customer isn't left charged for a half-itinerary that's useless without the missing leg. I'd test where in the sequence the failure occurs (first, middle, last), a supplier timeout that resolves late (the compensation must be idempotent so a late success doesn't re-book), and a payment that succeeded while a leg failed (money must be refunded). I'd verify the customer-facing state is consistent and not 'partially booked'. The signal is that across third parties, atomicity is achieved by compensation, not by a database transaction, so I assert the rollback path as carefully as the happy path.

Model answer

The dangerous state is money-taken, supplier-confirmation-unknown, so I'd stub the supplier to time out after payment and assert the system resolves deterministically rather than leaving the customer in limbo. The retry must be idempotent — using a booking reference the supplier dedupes on — so that if the original request actually succeeded, the retry returns the existing booking instead of creating a second one. If confirmation genuinely failed, the system refunds and tells the customer clearly. I'd test all three real outcomes of an ambiguous timeout: it succeeded (retry finds it), it failed (refund), and it's still processing (poll/queue and resolve). I'd add a reconciliation job that catches paid-but-unconfirmed bookings and resolves them, plus alerting. The customer-facing assertion is that they're never charged with nothing to show and never double-booked. This is the saga's hardest edge — an unknown outcome — so idempotency plus reconciliation is the design under test.

Model answer

Fare rules are a combinatorial space, so I'd drive the strategy from a matrix of fare type (non-refundable, flexible, semi-flexible) × action (cancel, change) × timing (inside vs outside the free-change window) × scope (one leg vs whole itinerary). For each cell I assert the correct outcome: a flexible fare cancelled in-window refunds in full; a non-refundable fare refunds only taxes or nothing per the rule; a change incurs the right fee, netted correctly against any fare difference; and a mixed itinerary applies each leg's own rule rather than one blanket rule. I'd verify money correctness to the cent and that the refund is confirmed on the supplier side, not just initiated — reconciling that the supplier actually processed it. Timing boundaries matter: a cancellation right at the free-change cutoff, and timezone effects on that cutoff. I'd automate the matrix with pairwise reduction to keep it tractable and gate the release on it. The signal is that refunds are rule-driven money movements across suppliers, so the matrix and the reconciliation are the strategy.