Testing software integrations without breaking your operation

An order sits neatly in the webshop but never arrives in the ERP. A customer gets created twice, with two different addresses. Or the invoicing integration gives out on the first of the month, exactly when the finance team has the least patience for it. These are not harmless technical hiccups. They are disruptions to the daily work, and clearing them up usually costs more time than preventing them would have.

So if you want to know how to test software integrations, the question "do these two systems connect?" will not get you far. That is the lowest bar there is. An integration is only reliable when data arrives at the right moment, in the right shape, and still behaves sensibly when something goes wrong along the way. That calls for a test approach built around your processes, not a quick trial with three random records.

Start with the business process, not the API

The mistake we see most often is testing from the technical side alone. A developer checks whether an API responds properly, ticks the box and moves on. But a successful status code tells you nothing about your process. It does not tell you that stock was reserved correctly, that a return was handled the right way, or that finance received the correct VAT amounts.

So map out the process the integration supports first. Which event starts the exchange? Which systems sit in between? Which data goes back and forth? And what has to be correct at the end for the employee, the customer or the bookkeeping?

Take an integration between a webshop and an inventory or ERP system. Do not just check that the order is passed along. Check that discounts, shipping costs, stock location, payment status and customer details come across intact. Then look at what happens with a cancellation, a partial delivery, and a product that sells out while someone is at the checkout. That is where real life starts.

Write down who owns the outcome of each step. The technical party watches whether the integration does what it should, but someone from the operation has to judge whether the data is actually usable. Otherwise you end up with a release that is technically a success and still creates noise on the floor.

How to test software integrations, step by step

Build your test approach in layers. Each layer catches a different kind of mistake. How deep you go depends on what is at stake: an integration that handles revenue every day deserves more attention than a nightly export to a reporting tool. The order below gives you something to hold on to.

Check the individual building blocks first

Test the parts in isolation. Can the system authenticate? Are all required fields being sent? Are dates, amounts and special characters formatted correctly? Does an error message from the other side actually get read and acted on?

This is also the level where you go looking for the edges. What happens with an empty field, a negative amount, or a response that cuts off halfway? Plenty of integrations run beautifully on tidy test data and fall over the moment reality deviates.

Pay particular attention to field translations. One system works with an internal article code, the other with an EAN or SKU. A field called "status" that means "paid" in system A can mean "shipped" in system B. Differences like these almost never produce a technical error. They produce wrong business data, and you tend to find out weeks later.

Then test the whole chain with scenarios that look like a working day

Next comes the full route: from the action that kicks off the process to the moment the last system has finished with it. One sample order with one product tells you almost nothing. A normal working day looks different.

Test orders with multiple lines, different VAT rates, a discount code, a separate delivery address and an existing customer. Then add the cases that come up less often but hurt when they do: a credit note, a duplicate request, a change after the parcel has already left, or an import of several thousand records at once.

Decide up front what the correct response is for each scenario. An order without a house number is perfectly welcome to produce a clear validation error. A duplicate webhook must never produce two invoices. Agree on that beforehand and reviewing becomes a matter of ticking boxes, which also saves you the argument after go live.

Test failures as if they are certain to happen

External systems go down now and then. Rate limits get hit, networks stutter, suppliers roll out a change without calling you first. The question is not whether that happens, but what your process does when it does.

So have your test environment deliberately return errors, time-outs and painfully slow responses. Does the integration retry? How often, and with how much time in between? Are you sure no duplicate transactions appear? And does a failed message become visible to someone who can do something about it? Logs are essential for working out what happened, but they are not an alert. If a failure only lands in a log file, nothing has been arranged operationally.

For critical processes a queue is often a smart move. If the other system is briefly unreachable, the integration holds the messages and processes them later. That does wonders for continuity, but it is not a licence to be slow: agree per process how quickly a message has to be handled, and make sure you can see when the queue starts growing. Count on messages getting stuck too, and decide who can clear those by hand.

Data is only correct when you can trace what happened

Integrations often fail quietly. The data arrives, but a piece of information is missing, gets overwritten, or ends up in the wrong field. Nobody sees an error, so nobody steps in. That is why checking afterwards is part of testing.

Compare source and target on counts, amounts and unique identifiers. For an order integration, check that the order number, total amount, customer ID and the individual order lines match on both sides. For a customer data sync, look at new, changed and deleted records, because that last one gets skipped almost every time.

Use test records you can find again easily, and record a correlation ID or sequence number wherever you can. That lets you follow a single event through the whole chain. It is worth its weight in gold the moment someone calls to say order 10428 is missing.

Keep privacy in mind while you do this. Representative test data means the shape, the variation and the volumes resemble real life, not that you drop a copy of your production database into an acceptance environment. If you do need real data to reproduce an awkward case, mask the personal details and limit who can reach them. A test that introduces a new security risk has rather missed the point.

Do not skip performance and peak load

An integration that handles ten messages an hour can behave very differently with a thousand messages in fifteen minutes. Think of a campaign, a newsletter going out, a month-end close, or a big import from a new supplier. So test the behaviour under pressure as well.

Measure how long processing takes, whether queues build up, and when you start bumping into the limits of external services. For live stock levels you want processing within seconds. For an accounting integration a few minutes is usually plenty. You make that call per process, and it drives the technology, the cost and what your users are entitled to expect.

Dependencies count too. When the website, the application, the database and the integration all live in different places, troubleshooting takes longer by default, simply because nobody has the full picture. A party that lines up development and hosting can look at logs, capacity and network behaviour in one go. You do not always need that, but on systems carrying daily revenue or customer contact, you feel the difference immediately.

Make acceptance measurable and arrange aftercare in advance

A test is only finished when everyone agrees on what "good" means. So set concrete acceptance criteria. For example: all required order fields come across correctly, a duplicate message does not cause duplicate processing, failures are visible to a named person within five minutes, and a temporary outage does not lose data.

Let the people who run the process every day join the testing. Someone on the customer service team will spot an unusable status field within a minute, while in the logs it looks entirely fine. Do give testers a narrow, concrete scenario and ask them to write down the result. Otherwise you are left with loose impressions instead of feedback you can use.

Arrange the aftercare once it is live right away. Who receives the alerts? Who judges the anomalies? Where do the logs live and how long are they kept? What do you do when the supplier retires an API version? An integration is not a delivery you tick off. Versions change, volumes grow and processes get adjusted along the way.

At LJPc we notice that this aftercare is exactly what separates an integration that was built once from an integration an organisation genuinely dares to lean on. Visibility into what is happening, a clear owner and the ability to act quickly are usually worth more than a thick technical report.

And no, you do not have to run all of this tomorrow. Take one critical process, write out the normal route and the exceptions, and decide what has to demonstrably go right. That is where you get an integration that does more than connect two systems: one that actually makes the work lighter.