Integration QA: a test checklist for partner builds

An integration ships, the demo is clean, and everyone moves on. Two weeks later a customer imports a spreadsheet with a blank email field, the sync silently drops half their records, and nobody notices until the customer does. The code was not wrong, exactly. It was untested against the one thing that was always going to happen: real data behaving badly. The demo tested whether the integration could work; nobody tested whether it would keep working when a real customer did something ordinary and unexpected.

An integration testing checklist is how you close that gap systematically instead of hoping you thought of everything. QA for an integration is not a single pass of "does it work"; it is a set of distinct test categories, functional, authentication, error handling, edge cases, and load, each of which fails in its own way and each of which a customer will exercise. A checklist turns testing from an ad-hoc scramble the day before launch into a repeatable discipline you run against every build, so the failure modes are found by you, on your schedule, instead of by a customer, on theirs.

This guide is that checklist, built for a partner integration where a failure is public and a partner is watching. We cover why integration QA needs categories rather than a single pass, each category in turn and what it tests, the failure modes that live inside each one, and a reusable checklist you can apply to any build. At the end you get a QA checklist and a failure-mode grid you can adapt to your next integration.

The 60-second version

If you only read one section, read this one:

• Integration QA is not one test; it is categories. Functional, authentication, error handling, edge cases, and load each fail differently, and a build that passes one can fail another badly.
• Functional tests are necessary but not sufficient. "It syncs a clean contact" is the easy case that was always going to pass. The other categories are where integrations actually break.
• Auth is a category of its own. Token expiry, refresh, revocation, and scope errors are where integrations fail days after launch, quietly, in production.
• Error handling is testing what the partner API does wrong. Rate limits, timeouts, and malformed responses are not your bugs, but they are your problem, and you have to test how you handle them.
• Edge cases and load are where the demo lied. Updates, deletes, duplicates, empty data, and real volume are the ordinary things a customer does that the happy-path demo never touched.
• A checklist makes QA repeatable. Run the same categories against every build, and you stop rediscovering the same failure modes one production incident at a time.

Why integration QA needs categories, not a single pass

The instinct to treat testing as one activity, "we tested it, it works", is what lets integrations ship with whole classes of failure unexamined. Software testing is not a single check; it is a set of different tests that answer different questions, and an integration exercises more of those categories than most features because it spans two systems, an auth boundary, a network, and someone else's data. A build can pass a functional test cleanly and still fail catastrophically on an expired token, a rate limit, or a customer importing ten thousand rows, because those are different questions that a functional test never asked.

Thinking in categories does two things. First, it makes your testing complete, because you can see which categories you have covered and which you have not, instead of testing whatever happened to occur to you. Second, it makes the failures legible: when something breaks in production, you can say "that was an error-handling gap" or "that was a load problem" and add the missing test, rather than treating every incident as a fresh mystery. The categories are the structure that turns testing from vibes into coverage.

These categories are not equally likely to be tested. Teams reliably test the functional category, because it is the one the demo covers, and reliably underinvest in the other four, because they require deliberately trying to break things rather than confirming they work. That asymmetry is exactly why the checklist matters: it forces attention onto the categories your natural testing skips. The conditions each category should verify are the same ones your integration acceptance criteria defined; the checklist is how you confirm the build actually meets them.

Functional and authentication testing

Functional testing verifies the core promise: on valid input, the integration does what it should. Contacts sync, in the right direction, with the right fields, at the right time. This is the category teams test well, because it is the happy path the demo is built around, and it is genuinely necessary, an integration that fails its functional tests is not ready for anything else. The trap is stopping here. Functional coverage answers "can it work," and a customer needs to know "will it keep working," which the remaining categories address. Test each workflow the integration promises, in each direction it claims to support, and confirm the data that arrives matches the data that left.

Authentication testing is a separate category because auth fails in its own distinctive way: not at launch, when you just set up fresh credentials, but days or weeks later, when a token silently expires or a customer revokes access. An integration that authenticates perfectly in the demo can stop working entirely on day three when the first access token expires and nothing refreshed it. You have to test the whole lifecycle, not just the initial handshake:

The reason auth deserves its own careful pass is that its failures are both delayed and quiet, the worst combination. A functional bug shows up immediately and loudly; an auth bug shows up next week, in production, as an integration that just stopped syncing with no obvious cause. Testing token expiry and refresh deliberately, by forcing an expiry rather than waiting for one, is how you find these before a customer does. The underlying mechanics of how this should work are covered in integration authentication, and a good sandbox that lets you simulate expiry is part of why the api sandbox guide matters for testing at all.

Error handling and edge case testing

Error handling testing verifies what your integration does when the other side misbehaves, and with a partner integration, the other side will misbehave. The partner API will rate-limit you, time out, return a malformed response, or go down entirely, and none of that is your bug, but all of it is your problem, because the customer experiences your integration failing regardless of whose fault it is. You have to test your behavior in the face of the partner's failures: does a 429 trigger a backoff and retry, does a timeout get handled rather than hanging, does a malformed response get caught rather than crashing the sync? The goal is that a partner-side failure degrades gracefully into a clear state, not a silent data-loss event.

Edge case testing covers the unusual-but-ordinary inputs that a customer produces without thinking and the demo never included. These are not exotic; they are the everyday reality of real data, and they are where integrations quietly lose or corrupt information. Walk the standing list for every build:

The discipline for both categories is the same: you have to deliberately try to break the integration, because these failures do not appear when you use it correctly. This is the opposite mindset from functional testing, where you confirm success; here you manufacture failure, an expired token, a rate limit, a blank field, a duplicate, and check that the integration handles it without losing data or hanging. This is the same edge-case thinking that acceptance criteria demand, and getting the error behavior right depends on understanding good API error design on both sides of the boundary, because a partner's errors are only as handleable as they are legible.

Load and regression testing

Load testing answers the question the demo can never answer, because the demo uses one record and a customer uses thousands. An integration that syncs a single contact in a demo can fall over when a customer connects an account with fifty thousand records and triggers a full initial sync, hitting rate limits, exhausting memory, or timing out halfway through and leaving the data in an inconsistent state. Load testing means exercising the integration at realistic customer volume, and then at more than that, so you find the ceiling before a customer does. Test the initial bulk sync, the steady-state throughput, and the behavior when volume spikes, and confirm that hitting a limit degrades gracefully rather than corrupting the sync.

Load reveals a distinct class of problems that low-volume testing hides entirely: rate-limit exhaustion, pagination bugs that only appear past the first page, memory growth on large batches, and partial-failure states where a sync dies halfway and leaves records inconsistent. None of these show up when you test with a handful of records, which is exactly why they reach production, because low-volume testing is what most teams do by default.

There is one more category worth adding to the checklist, especially for an integration you will maintain for years: regression testing. Every time you change the integration, or the partner changes their API, you risk breaking something that used to work. Regression testing is re-running the checklist against a changed build to confirm the change did not break a previously-passing case. For an integration, the trigger is often not your own change but the partner's: a partner API update can break your integration without you touching a line, which is why the checklist is not a one-time launch gate but a standing instrument. Catching those breakages is exactly what ongoing integration monitoring is for, and the QA checklist is what monitoring alerts you to re-run.

Common mistakes, and the fix

Testing only the functional happy path. The fix: run all five categories, functional, auth, error, edge, and load, because a build that passes the demo can fail catastrophically on an expired token or a large sync. The happy path is the case that was always going to work; the other categories are where integrations actually break.

Treating authentication as a one-time setup. The fix: test the whole auth lifecycle, expiry, refresh, revocation, and scope errors, by forcing an expiry rather than waiting for one. Auth failures are delayed and quiet, showing up days later in production, which is the worst way to discover them.

Assuming the partner API always behaves. The fix: test your error handling by manufacturing partner-side failures, rate limits, timeouts, malformed responses. The partner's failures are not your bug but they are your problem, and a customer experiences your integration failing regardless of whose fault it is.

Skipping load testing because the demo worked. The fix: test at realistic volume and beyond, because a demo uses one record and a customer uses thousands. Rate-limit exhaustion, pagination bugs, and partial-failure states only appear at scale, which is exactly why they reach production undetected.

Testing once and never again. The fix: keep the checklist as a standing instrument and re-run it after any change, on either side, since a partner API update can break your integration without you touching a line. QA is not a launch gate you pass once; it is a discipline you repeat.

FAQ

What is an integration testing checklist? It is a reusable set of test categories, functional, authentication, error handling, edge cases, and load, that you run against every partner integration to find failure modes systematically instead of hoping you thought of them. Each category fails in its own way, so the checklist is what turns QA from a single "does it work" pass into complete coverage of the ways an integration actually breaks.

Why isn't functional testing enough? Because functional testing answers "can it work on good input," which is the happy path the demo already covers, and a customer needs "will it keep working" when a token expires, the partner API rate-limits you, or someone imports fifty thousand messy records. Those are different questions in different categories, and a build can pass functional tests cleanly while failing all of them.

Why is authentication its own test category? Because auth fails in a distinctive way: not at launch when credentials are fresh, but days or weeks later when a token expires, a refresh fails, or a customer revokes access. These failures are delayed and quiet, an integration that just stops syncing with no obvious cause, so you have to test the whole lifecycle by forcing expiry and revocation rather than waiting for them.

How do I test error handling for a partner integration? By manufacturing the failures the partner API will eventually produce: rate limits, timeouts, malformed responses, and outages. Confirm that a 429 triggers backoff and retry, a timeout is handled rather than hanging, and a bad response is caught rather than crashing the sync. The partner's failures are not your bug, but the customer experiences your integration breaking, so handling them is your responsibility.

What edge cases should I test? The unusual-but-ordinary inputs real customers produce without thinking: updates, deletes, duplicates, empty or partial data, special characters like unicode and emoji, and timezone or format differences. These are not exotic; they are everyday real data, and they are where integrations quietly lose or corrupt information because the happy-path demo never included them.

Do I really need load testing? Yes, because the demo uses one record and a real customer connects an account with thousands, triggering bulk syncs that hit rate limits, exhaust memory, or die halfway and leave data inconsistent. Load testing at realistic volume and beyond finds these ceilings before a customer does. Rate-limit exhaustion and pagination bugs simply do not appear at the low volumes most teams test with.

How often should I run the checklist? After every change, on either side. Your own changes can regress a previously-passing case, and a partner API update can break your integration without you touching a line. That makes the checklist a standing instrument rather than a one-time launch gate, and it is what your integration monitoring should prompt you to re-run when it detects a problem.

Further reading

• Wikipedia, software testing, on why testing is a set of distinct categories answering different questions.
• Wikipedia, test case, on the structure of a single verifiable test with inputs and expected results.
• Wikipedia, load testing, on exercising a system at realistic and elevated volume to find its ceiling.
• Wikipedia, regression testing, on re-running tests after a change to confirm nothing that worked broke.
• OWASP, Top Ten, on the common security risks a partner integration should be tested against.

The short version

Integration QA is not a single "does it work" pass; it is five categories that each fail in their own way: functional, authentication, error handling, edge cases, and load. Teams reliably test the functional happy path, because it is what the demo covers, and reliably skip the other four, because those require deliberately trying to break things rather than confirming they work. That asymmetry is exactly why a checklist matters, it forces attention onto the categories your natural testing avoids.

Test each workflow functionally, then push on the parts that fail quietly in production: the full auth lifecycle including expiry and revocation, your handling of the partner API's rate limits and timeouts, the ordinary edge cases like updates, deletes, duplicates, and empty data, and real customer volume that the demo never approached. Keep the checklist as a standing instrument and re-run it after any change on either side, because a partner API update can break your integration without you touching a line.

If you want the whole path handled, from partner strategy and a partner-ready API through a scoped, thoroughly-tested build to launch and adoption, that is exactly what a Partner Audit is for. We review your product, API, and partner potential, then define what to build, how to test it, and how to ship and prove it together.