Telegram Bot Acceptance Checklist: 7 Tests Before Final Handover

A bot replying to a greeting proves that one conversation works. Handover needs evidence that the owner controls the system, repeated actions stay safe, and a broken dependency does not quietly lose a request.

Use these seven tests for a booking, enquiry or support bot. Agree the expected outcome before the demonstration. Run disruptive tests in an agreed test environment with disposable records; do not stop a production service to discover whether it recovers.

A sign-off table you can reuse

For each row, record PASS, FAIL or NOT TESTED, the tested version, date, operator and evidence location. A demonstration with no evidence remains NOT TESTED. Replace the example outcomes with the requirements of your project.

On a narrow screen, scroll the table horizontally.

Copy this record beneath each row into your acceptance document:

Requirement:
Tested version and date:
Input and action:
Expected business outcome:
Observed outcome:
Evidence location:
Verdict: PASS / FAIL / NOT TESTED
Defect owner and retest date:

1. Confirm ownership and access

The owner should see the bot in the appropriate BotFather account and control the hosting, source repository and integration accounts. A token supplied by a contractor is not an ownership record.

Ask for an access inventory showing who can administer each dependency and how access can be revoked. Transfer secrets through the agreed secure channel, never in screenshots or acceptance notes. If the project is already stranded with a departed supplier, use the separate bot recovery guide.

2. Repeat a business action

Confirm the same test booking repeatedly, including from two sessions if the application supports them. Inspect the booking store or CRM, not just the conversation. Expect one committed record and a clear response to repeats.

Ask the developer to replay the same test update at the application boundary as well. Repeated button presses and redelivery are different cases. Both should follow the agreed duplicate-handling policy. A disabled button alone does not protect the backend.

Telegram’s callback acknowledgement clears the client’s waiting indicator. It does not prove that a booking was saved. Keep acknowledgement and business confirmation separate in the evidence.

3. Send invalid input and reset

At a text step, send a sticker. Paste an invalid email, then correct it. Go back a step and cancel the process. Start again and check that values from the abandoned request do not reappear.

The bot should explain what input it accepts without crashing or inventing success. Record validation messages and the final stored fields. Test only input sizes agreed in the specification; uncontrolled flooding is a different exercise.

4. Restart during a request

Begin a test enquiry, save a draft if supported, and have the operator restart the service. Check the agreed behaviour: resume at a known step, or clearly ask the user to restart. Confirm that completed records survive.

A process automatically starting again is different from data recovery. Ask for a restore rehearsal using a test backup, including the restored record count and a sample enquiry. A backup file that has never been restored is incomplete evidence.

5. Try a forbidden operation

Using two authorised test accounts, attempt to view or change the other account’s booking. For an AI bot, ask it to ignore its instructions and perform that same operation.

The decisive outcome is no unauthorised read or write. A polite refusal in chat is insufficient if a tool still executed. Inspect the target record and operation log. See four controls beyond the prompt for the architecture behind this test.

6. Interrupt an integration

In the test environment, make the CRM or notification destination temporarily unavailable. Submit a request. The bot should report the state accurately: accepted locally and awaiting delivery, or rejected with a usable retry path, according to the contract.

Restore the dependency and inspect what arrives. Pending work should recover without duplicate records or endless retries. Capture the original request identifier, pending state and final result. A success message must not conceal a lost request.

7. Rehearse handover and support

Have a second operator follow the runbook: locate the running version, check service health, find a failed request and identify the recovery procedure. Confirm repository access, deployment instructions, backup ownership and the support contact.

Agree how incidents are reported, what acknowledgement means, who can restore service and which dependencies are outside the supplier’s control. These are operational acceptance terms; legal contract wording needs separate review.

Why passing checks can still miss the gate

In one lab review recorded on 22 July 2026, a suite of 14 passing checks included a detector that correctly flagged a schema version mismatch. The main check ignored that flag and returned success. Its gate test covered a missing field, leaving the version mismatch route untested.

This is one recorded incident, not an estimated failure rate. Its lesson applies to bot handover: test the route from input to final business effect. A validation function returning the correct answer does not prove the application acts on it. The verification gate guide covers the engineering side.

Attach failures to the handover record and retest the affected scenario after a fix. For an independent acceptance review, Request a scope with the bot’s intended workflow and the existing acceptance evidence.