Integration testing checklist before production

Short answer

Before going to production, an integration should pass eight groups of tests: functional scenarios, data and formats, error cases, duplicates and resends, volume and limits, security, monitoring and alerts, and rollback. The expected result for each test is written in advance, and the outcome is recorded as passed, failed or not applicable. The business owner and the technical owner sign off the final result in writing. Testing a chatbot's dialogues is separate work; this checklist tests the data flow between systems itself.

Why you need a checklist

Integration tests often end with "it works": a developer sends one test lead, sees it in the CRM, and the job is considered done. The problems appear in production: a customer whose name contains an Azerbaijani letter such as "ə" has it turned into symbols, a lead arriving at night has its date shifted by a day, leads are lost while the CRM is being updated. None of this shows up in a "happy path" test.

A checklist forces testing from a written list rather than whatever comes to mind, and answers "did we check that?" afterwards.

1. Functional scenarios

• The normal case of each business scenario: a lead is created with the right fields and assigned to the right manager.
• Alternative cases: the customer already exists, there is no number, a two-intent enquiry.
• Status changes flow both ways as expected.
• Expected delay: the event appears in the target system within the agreed time.

2. Data and formats

• Azerbaijani letters — ə, ş, ç, ğ, ı, ö, ü — stay correct in names, addresses and notes.
• Mixed Cyrillic and Latin text, emoji and long messages.
• Phone formats: 055…, +99455…, with spaces and brackets.
• Date and time: an event close to midnight, time-zone differences.
• Empty fields: a field empty in the source does not wipe a correct value in the target.
• Long text: is a summary longer than the target field's limit cut, and how?

How the field map is written is shown in the CRM integration data mapping checklist.

3. Error cases

• The target system does not respond: the request is not lost and is retried.
• Timeout: a retry does not create a second record.
• The key is wrong or expired: an alert arrives immediately.
• Data fails validation (a required field is empty, say): the request goes to a queue and a person sees it.
• The limit is exceeded (429): the system waits and then continues.

The rules for this behaviour are covered in API error handling and retry rules.

4. Duplicates and resends

• The same event is sent twice — one record remains in the target.
• The same customer arrives from two channels — the rule works as expected.
• In two-way sync, a change does not bounce back and create an endless loop.
• Two parallel requests try to create the same record — one remains.

The causes of technical duplicates are covered in duplicate data between systems.

5. Volume and limits

Run a short test at several times the expected daily volume — simulating a campaign day, for example. Things to watch: does latency grow, are requests lost, is the other side's limit reached, how fast does the queue drain? Run this in the test environment, not against the live system.

6. Security

• Test and live keys are separate, and keys are not in code.
• The integration account has only the permissions it needs.
• The webhook address does not accept requests without a signature or key.
• The log holds no unnecessary personal data.
• AI tools only reach permitted addresses.

7. Monitoring and alerts

Before production, the alerts themselves are tested: create an artificial error and check the alert reaches the right person on the right channel. A monitoring dashboard or report should show the integration's state: when the last successful delivery was, how many requests are queued, how many errors occurred in the last hour.

8. Rollback

The most forgotten test: how do you switch the integration off? The rollback plan must be tested — the integration is stopped with one button or setting, no data is lost meanwhile (it stays queued or is handled by hand), and when it is switched back on the queue is processed correctly. An untested rollback plan may not work during an incident.

How to record results

1. 1TestWhat is checked, with which data.
2. 2Expected resultWritten in advance, not after the test.
3. 3Actual resultPassed, failed, not applicable — with evidence (a screenshot, a log entry).
4. 4DecisionFor a failed test: a fix, risk acceptance (with the reason) or postponing go-live.
5. 5Sign-offWritten approval from the business and technical owners.

An illustrative example

This is an illustrative example. An insurance agency's chat-to-CRM integration passes the functional tests. The data group, however, turns up two problems: a customer's name with Azerbaijani letters shows in the CRM garbled, and a lead created at 23:50 lands on the next day. The rollback test reveals that switching the integration off needs a developer.

Three fixes are made: encoding, time zone, and a setting in the dashboard to pause the integration. Only then is the checklist signed and the integration taken live.

Common mistakes

• A single "happy path" test.
• Writing the expected result after the test.
• Not checking Azerbaijani letters and time zones.
• Not testing alerts.
• Not testing the rollback plan.

Limitations

Even the fullest checklist does not cover every case in production. So the first week after go-live needs heightened monitoring and a daily sample check. If the test environment differs from live, test results may differ too — how the test environment is built is covered in the AI integration sandbox.

Integrating with Vexvon

When integrating with Vexvon, channels are checked with test conversations before they go live, website widget test conversations are kept out of reports, and call routing is tried with a simulation. For webhooks and company APIs, we write the test checklist — which scenarios, which error cases and the acceptance criteria — together in the integration plan. More on integrations.

Next step

For your next integration, copy the eight groups into a table and write at least two tests for each, with the expected result. Testing chatbot dialogues is covered separately in the chatbot test list. More articles are in the enterprise integration section, and we can review your checklist together during a demo.