Как протестировать бота перед запуском

Почему «попробовать пару вопросов» не считается тестом

Соблазн после создания бота — написать ему «здравствуйте» и «сколько стоит», убедиться, что ответ появился, и на этом закрыть тему. Формально бот работает. По факту проверены два самых простых, самых предсказуемых случая — именно те, где бот и так вряд ли ошибся бы. Настоящая проверка устроена иначе: она целится в те места, где бот может подвести, а не в те, где он точно справится.

Четыре шага, которые стоит пройти до запуска

1. Возьмите реальные вопросы из своей переписки за последний месяц. Не придумывайте тестовые фразы — откройте историю сообщений в любом мессенджере, где вам уже писали клиенты, и введите боту пять-десять настоящих вопросов дословно, как их написали живые люди: с опечатками, сокращениями, не всегда вежливой формулировкой. Придуманные вами тестовые вопросы почти всегда чище и понятнее реальных — и именно поэтому ничего не показывают.
2. Попробуйте бота сломать. Задайте вопрос, который заведомо выходит за рамки описания задачи — что-то не по теме бизнеса или откровенно абсурдное. Хороший результат — бот честно признаёт, что не может ответить, и предлагает обратиться к человеку. Плохой — бот уверенно выдаёт правдоподобный, но выдуманный ответ. Второй вариант опаснее первого: клиент не всегда способен отличить уверенную выдумку от факта, а вот отказ ответить он распознает сразу.
3. Протестируйте из настоящего канала клиента, а не только из панели конструктора. Поведение и скорость ответа в предпросмотре внутри админки не всегда совпадают с тем, что видит клиент в самом мессенджере — на телефоне, с реальной задержкой сети, с настоящим интерфейсом приложения. Пройдите путь клиента буквально: откройте Telegram или WhatsApp на своём телефоне и напишите боту так, будто вы клиент, а не разработчик.
4. Дайте протестировать тому, кто не писал описание. Человек, который сам формулировал задачу бота, уже знает, какой ответ считается «правильным», и подсознательно задаёт вопросы так, чтобы бот на них ответил хорошо. Коллега, который ничего не знает о том, что вы туда написали, задаст вопросы иначе — так, как их задал бы настоящий сторонний клиент, и с большей вероятностью найдёт дыру, которую автор описания просто не мог увидеть.

Что делать с тем, что нашли

Каждый провал теста — это не повод паниковать, а конкретная правка в описание задачи: если бот выдумал ответ там, где нужно было признать незнание, добавьте в описание прямую инструкцию честно отвечать «не могу ответить точно, уточню у менеджера» на вопросы вне темы. Если тон не совпал с ожиданиями — поправьте формулировку тона. Тестирование имеет смысл только вместе с готовностью тут же вносить изменения, а не собирать список проблем «на потом».

Пример из практики теста «сломать бота»

Бот кофейни, которому в описании дали задачу отвечать про меню и цены, на вопрос «а вы доставляете кофе в офис в другом районе» уверенно ответил «да, доставка работает, уточните адрес» — хотя никакой доставки у кофейни нет и в описании про неё не было ни слова. Это ровно тот случай из шага 2: бот не отказался отвечать, а сочинил правдоподобный ответ, потому что вопрос звучал логично рядом с темой меню. Правка заняла одну фразу в описании — «если спрашивают про доставку, честно говори, что её нет, и предлагай самовывоз» — и при повторном тесте бот перестал выдумывать. Без этого конкретного проверочного вопроса проблема осталась бы незамеченной до первого клиента, которому назначили несуществующую доставку.

Итог

Проверка бота до запуска стоит меньше часа, а разница между протестированным и непротестированным ботом обычно видна уже в первый день реальной работы. Дешевле найти слабое место самому, задавая неудобные вопросы заранее, чем узнать о нём от клиента, который наткнулся на него первым.