Testing Coordination Failures between Systems

Here's a test strategy lesson that a decade of fintech and SaaS testing didn't fully teach me, but a live operational system did.

For over a decade, I worked as a QA engineer testing payment systems, lending platforms, healthcare applications, and SaaS products across Africa and Europe. My job was to find the defect before a customer did using automation, exploratory testing, API validation, and systems thinking.

I got hands-on operational exposure to a different kind of system when I helped build the software behind Kajuju, a boutique lodge in Kenya. I expected the learning curve to be operational, service standards, guest experience, the things a software engineering background doesn't obviously prepare you for. Instead, I found myself relearning systems engineering, and it changed how I think about test strategy.

Coordination Failures

Every day exposed workflows where multiple systems had to agree with each other: reservations, payments, housekeeping, guest communication, availability across booking channels. Individually, each piece usually worked. A booking form submitted correctly. A channel manager sync. A WhatsApp message got a reply.The friction showed up in the handoffs, the gap between one system updating and another system finding out about it especially where done manually.

The Excel Sheets

Alongside every workflow, we kept a manual Excel sheet, not because anyone was resistant to the tooling, because the channel manager, for all its API access, didn't give full visibility into everything staff needed to see in one place. So a spreadsheet persisted quietly in the background as the thing we actually trusted.

Excel sheets existed as our shadow system because our hospitality system didn’t represent how the work actually happened. It's usually a sign that the systems workflows don’t represent the various ways small lodges and restaurants are running.

Why Hospitality Software Behaves Like a Distributed System

A booking engine sounds like a simple CRUD problem: create a reservation, block some dates, take a payment. In theory, this is true, but multiple edge cases exist within this flow, and have to be reconciled and updated constantly. The assumptions made are what cause the hiccups in using hospitality tech systems.

Bugs That Arise

The clearest example was a timezone drift bug in the double-booking detector I built. The original check compared checkout and checkin dates using JavaScript's new Date(), which parses a bare date string as midnight UTC. The property runs several hours ahead of UTC, so a checkout and a checkin on the same calendar day looked, to the code, like they overlapped by a few hours. The fix was to stop comparing Date objects and start comparing plain YYYY-MM-DD strings instead — timezone-agnostic by construction. The false-positive alerts that only surfaced in cross-timezone CI runs disappeared entirely.

It's a small bug technically. But it's a good proof point for the larger claim: the failure wasn't in the booking logic, the payment logic, or the messaging logic. It was in an assumption about how two systems would agree on what "the same day" means.

Trust and Monitoring

The other lesson was about what makes monitoring worth trusting. Early on, false-positive alerts made the monitoring noisy enough that it was tempting to start ignoring it, which defeats the entire point of having it. Once the timezone bug was fixed and the noise stopped, an alert firing meant something real, and got treated that way. Monitoring only earns trust by being boring and accurate for a long stretch of time. That's true whether it's watching a payment pipeline or a booking calendar.

Closing Thought