When integrating a large model with a business system, acceptance testing cannot focus only on whether it can return an answer

First define the start and end of a business task

A demo page generating a piece of text does not mean that the business system has completed the task. Take “generate a follow-up summary after receiving customer materials” as an example: it is necessary to clarify where the materials come from, who can read them, who confirms the summary, and which business record it is ultimately saved to.

The deliverables for interface integration should be described around this task chain. The model, page, workflow, and existing system should each have a clearly defined role, and the person responsible for taking over after a failure should be identifiable both in the flowchart and in the actual interface.

Agree on input and output formats that can be checked

• Input: required fields, file types, length limits, and handling of empty values.
• Output: field names, data types, permitted enumerations, and the original evidence that must be retained.
• Status: how waiting, processing, requiring human action, completed, and failed states are presented.
• Identity: operator, task ID, associated business record, and creation time.

The business system must validate the returned results. If required fields are missing or the format does not meet the agreed requirements, the task should enter a clearly defined exception workflow rather than displaying success and leaving the user to search for missing information afterward.

Test permissions and usage scope by role

Distinguish permissions for reading materials, calling the model, confirming results, and writing back to the system. Run the same workflow with a standard business account and an administrator account, and verify the accessible scope and executable actions for each.

What a connector can access should not be determined solely by page buttons. The server side should also check permissions and retain necessary operation records. Interface credentials should be provided through controlled configuration, avoiding placement in public webpages or the body of logs.

Timeouts, rate limits, and repeated operations must be included in acceptance testing

Microsoft’s documentation on retry patterns reminds us to distinguish potentially recoverable temporary failures from persistent failures, and to consider the maximum number of attempts and the side effects of repeated execution. This article converts these principles into business acceptance questions without assuming that any fixed number of retries is suitable for all systems.

• Model timeout: Does the page stop waiting and display the task status, and is the backend still processing?
• Call restriction: Is processing delayed according to policy, and are there limits on the total number of attempts and the maximum wait time?
• Repeated clicks: Is the same task recognized, and is the business record written more than once?
• Lost acknowledgment: If the target system may have already completed the task, can it be queried before retrying?
• Persistent failure: Can the relevant tasks be paused and handed over to the responsible person instead of sending requests indefinitely?

Costs and failure handover are also part of the deliverable

At a minimum, it should be possible to view the call volume, number of failures, and retry consumption by task or business scenario. The pilot budget should also account for model calls, related services, system deployment, and maintenance. Specific costs are subject to the services actually selected and the contractual terms.

Handover materials should include configuration locations, permission owners, log entry points, troubleshooting steps, rollback methods, and the scope of support. Business users should know “where to look, whom to contact, and whether to resubmit when this task gets stuck.”

Use a set of task samples for the final verification

Select normal tasks, tasks with missing information, tasks without access permissions, and tasks simulating timeouts or duplicate submissions. Record the expected result, actual result, and outstanding issues for each. Recovery operations must also be verified; it is not enough to leave a note saying “retries are supported.”

When consulting, you can provide the names of existing systems, available interface documentation, a typical business process, and anonymized samples. First confirm the scope of reading and writing, then discuss the specific division of responsibilities for AI application development, model integration, deployment, and maintenance.

References and Scope

• Microsoft Learn：Retry pattern: Retries need to account for temporary and persistent failures, attempt limits, and idempotency; when an acknowledgment is lost, repeated execution may produce side effects.

The references above illustrate the technical approach. The implementation steps and acceptance recommendations in this article were compiled by the editorial team and are not evidence of results achieved by third-party customers.