What ‘tested with test data’ means: what an integration needs before real use

Testing with test data means the software was run against a prepared, fixed set of inputs, called fixtures, and produced the expected results. It proves the code handles those cases. It does not prove the partner will accept them, because going live needs the partner's authority, its credentials and its own test environment.

A vendor says the integration is ready. The hotel hears that bookings start on Monday. Between those two sentences sit a contract, a set of credentials and a test window that nobody has mentioned yet. This article explains what test data actually proves, what the other side must grant before anything goes live, and what integration pre-production testing is. After reading, you will be able to put a short set of specific questions to any vendor, including ours.

Why do ‘ready’, ‘tested’ and ‘in use’ sound the same?#

Because each word describes a different party's work, and a vendor will use the shortest word that is still true. The three claims are not equally strong.

Ready usually means the code exists and runs on the vendor's side. It says nothing about the other side of the connection. Tested means it ran against data someone prepared, not against the partner's live rules and limits. In use means a real booking, invoice or guest record has passed through, and a named person is accountable when it goes wrong.

The distance between tested and in use is rarely technical skill. It is permission, credentials and a test window the partner must open. Vendors are not lying when they say ready. The word is accurate and the reader supplies the rest, which is the problem. A useful habit is to ask which of the three the vendor is claiming, and write the answer into the contract or the meeting note. For a fuller vocabulary, see the five status words AI Otel uses and what each one claims.

What does testing with test data actually prove?#

It proves the software handles the shapes and sequences someone prepared for it, and produces the results that person expected. That is a real and useful proof, and it stops well short of the partner's live system.

A fixture is a fixed set of inputs kept with its expected output, so the same test can be rerun after every change. Fixture testing means running the software against those stored cases. What it can prove: the data is read and mapped correctly, dates and currencies convert as intended, errors are caught, a retry does not create a second booking, and a rejected request fails cleanly instead of half-succeeding.

What it cannot prove: the partner's real validation rules, its rate limits, its timeouts, its certificate and address requirements, and the small differences between its documentation and its behavior. Test data is friendly data. It rarely contains the cases that break integrations: a rate built from three pricing rules at once, a cancellation just after midnight, a guest name with characters the partner rejects.

A test that only walks the successful path is a demonstration, not a test. The value sits in the rejected, duplicated and timed-out cases. Keep the fixtures, version them and rerun them on every release. A test that is not rerun tells you what was true on one afternoon. If the plumbing itself is unfamiliar, hotel PMS integrations explained in plain words covers how systems talk to each other.

What must the other side give before an integration can go live?#

Two things, and neither belongs to the vendor: the authority to act, and the credentials that open the partner's systems.

Authority is a permission question. Someone must be allowed to send this hotel's rates, availability or guest data to that party, and the contract should say who is responsible when a rate is wrong or a guest record is mishandled. Credentials are the practical side: an account, a key or a token, a property identifier, sometimes a certificate and a list of allowed network addresses. Each one is issued by the partner, not built by the vendor.

For electronic invoices and fiscal flows, a licensed integrator sits between the hotel and the authority. Without that integrator's onboarding, nothing is issued, however good the software is. Access is usually per property and per environment. A group with ten hotels needs ten setups, and a test setup that is separate from the live one.

Each side needs a named person who can approve the switch, because the last step is a decision, not a deployment. Ask early. Credential requests can take longer than the code, and they are the reason a finished integration sits idle.

What is a pre-production environment?#

A rehearsal space that behaves like the partner's live system but moves no real money, rooms or guests. Integration pre-production testing means the software is running there, against the partner's own rules, before anything real passes through.

It is separate by design: separate credentials, a separate property or account, separate data. Nothing done there reaches a guest or a bill. It exists to run the whole path end to end, including the failures: a rate the partner rejects, a timeout, a duplicate request, a cancellation that arrives twice.

It is also where the partner runs its own acceptance checks, which is the part a vendor cannot do alone. As a status, pre-production sits between built and live. The software is finished and being exercised; it is not yet carrying real bookings. What ends it: the partner's sign-off, production credentials, a rollback plan, and a person watching the first days of real traffic.

To make this concrete with our own case: availability and rates flow from the hotel's system to the major OTAs through our Channex integration, now in pre-production testing. No booking site is connected today. That integration sits inside a wider design, one room inventory feeding the website, booking sites, agencies and AI assistants.

Where does AI Otel stand on integrations?#

Built and fixture-tested; going live needs the authority and integrator credentials. That sentence is the whole position, and it applies across our integrations.

The first half says the software exists and has been exercised against prepared test data. The second half says the remaining work belongs to institutions and partners, not to us. Booking sites: built, in pre-production testing through our Channex integration. We do not claim a connection to any booking site, and we do not display their logos.

The distribution hub is built with seed data, so hotels publish contracted rates to travel agencies on their own terms and every quote shows its working: the hotel's net, each pricing rule that fired, the final price. No agency is connected yet. The partner API is built, with no partner connected; partners and AI assistants would connect through a versioned, secured booking interface.

Fiscal devices and door locks are architected: designed to connect ÖKC fiscal devices outlet by outlet, and designed for the major door-lock vendors. We give no date for any of these going live, because the date depends on credentials we do not hold. What those designs cover is described in door locks and fiscal devices: what the operating system is designed to connect.

What should a hotel ask when a vendor says an integration is ready?#

Ask which claim is being made, who on the other side has approved it, and what happens on the first wrong rate. Those three answers separate a finished product from a finished sentence.

Ask for the partner's name and the environment, and whether the partner's own staff have run their checks there. Ask who holds the credentials today, and who will hold them on the day it goes live. Ask what the test covered beyond the successful path, and whether the same tests are rerun on every release.

Ask who is accountable if a rate reaches a booking site wrong, and how it is corrected and recorded. Ask what the rollback is, and who is watching the first days of real traffic. Ask for the answer in writing. A status that only exists in a sales call cannot be checked later.

What to do next#

The next step is a written question to whoever last told you an integration was ready: which partner, which environment, who approved it, and who holds the credentials. The three words ready, tested and in use describe three different states of the world, and only the last one puts a real booking through your hotel. Everything else in this article is a way of telling them apart before you plan around them. If you want to see how we state our own integration status, you can request a briefing.