Тест бота и сайта перед запуском: что проверить самому

Страх запустить сломанное

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

Исполнитель тестирует свою работу сам, но он знает, как бот должен работать, и нажимает правильные кнопки в правильном порядке. Заказчик, который принимает работу, смотрит иначе. Ниже мой список для этой приёмки. Что собрать до начала разработки, я разбирал в чек-листе заказчика, а что должны передать после сдачи, в тексте про сдачу проекта. Здесь речь только о проверке перед запуском.

Сценарии по ролям

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

• Клиент: найти бота или сайт, начать, записаться или оформить заказ, получить подтверждение, отменить или перенести.
• Сотрудник: увидеть новую заявку, принять её, изменить статус, написать клиенту.
• Администратор: добавить услугу или товар, поменять цену, закрыть слот, выгрузить отчёт, выдать и забрать доступ у сотрудника.

Отдельно проверьте, что роли не пересекаются. Сотрудник не должен видеть выручку, клиент не должен попасть в админку по знакомой ссылке.

Плохие входы

Живые люди делают то, чего не предусмотрел сценарий. Поэтому вторая часть проверки состоит из намеренной порчи. Вот что я прошу попробовать:

• отправить пустое сообщение, один пробел, очень длинный текст, смайлики вместо ответа;
• ввести телефон буквами, дату в прошлом, отрицательное количество;
• прислать голосовое, фото или файл там, где ждут текст;
• нажать кнопку из старого сообщения, выше по переписке, когда сценарий уже ушёл дальше;
• дважды быстро нажать «Оплатить» или «Записаться»;
• написать «стоп», «отмена» или «оператор» в середине сценария.

Хороший бот в этих случаях вежливо переспрашивает или возвращает на шаг назад. Плохой молчит, падает или создаёт дубль заказа. Если нашли дубль, это серьёзная находка: после запуска такие дубли пришлось бы разгребать руками.

Два-три дня на своих людях

Собственной проверки мало. Дайте систему трём-пяти людям, которые не участвовали в разработке: сотрудникам, знакомым клиентам, родственникам. Не объясняйте, как ей пользоваться. Скажите только, что нужно сделать, например «запишитесь на среду».

Через два-три дня соберите наблюдения и посмотрите, где люди остановились, что переспрашивали и что нажали не туда. В такой выборке всегда находятся ошибки, которых никто из команды не видит. В разборе этапов по неделям этот шаг стоит перед запуском, и я стараюсь не сокращать его, даже когда срок поджимает.

Уведомления и оплата на тестовых данных

Проверьте, что сообщения доходят туда, куда должны: менеджеру приходит заявка, клиенту подтверждение, администратору сигнал об ошибке.

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

Персональные данные в тестах заменяйте вымышленными: выдуманные имена, телефоны и адреса. Реальные данные друзей и клиентов оседают в тестовой базе и журналах, а потом о них забывают.

Телефоны, копии и план отката

Откройте всё минимум на одном новом и одном старом телефоне, на Android и на iPhone, с мобильным интернетом вместо Wi-Fi. В мессенджерах проверьте и свежую версию приложения, и устаревшую: у части клиентов обновления отключены.

Потом переходите к скучному, но решающему. Попросите показать резервную копию и восстановите её хотя бы в тестовой среде. Копия, которую ни разу не разворачивали, остаётся предположением. О том, как её организовать, я писал в разборе резервного копирования. Проверьте и доступы: домен, сервер и аккаунты должны быть записаны на вас, и вы сами должны уметь в них зайти.

Наконец, план отката. Он отвечает на вопрос, что вы будете делать, если в первый час всё пойдёт плохо. Мне хватает четырёх строк: кто принимает решение, как быстро отключить новую версию или вернуть старую, что сказать клиентам, кому звонить. Пока этого нет, запускаться рано.

Что важно учесть

Тест не гарантирует отсутствия ошибок. Пять человек за три дня нажмут меньше, чем пятьсот за неделю, и какая-то странность всё равно проявится на живых клиентах. Это нормально, если она не трогает деньги и данные и если вы заметите её в день появления.

Поэтому первую неделю после запуска я смотрю не меньше, чем тестирую до него. Что отслеживать:

• число начатых и завершённых сценариев: если доля завершённых резко упала, где-то сломан шаг;
• ошибки в журнале и ответы бота «не понял»;
• оплаты: сколько создано, сколько прошло, нет ли зависших;
• время первого ответа менеджера на заявку;
• обращения клиентов, которые начинаются словами «у меня не работает».

Что можно сделать уже сейчас

1. Выпишите роли и по три главных действия для каждой. Это ваш список приёмки.
2. Выберите тестировщиков: троих сотрудников и двух знакомых клиентов. Предупредите их заранее.
3. Спросите у исполнителя, как включить тестовый режим оплаты и где лежит резервная копия.
4. Напишите план отката из четырёх строк и повесьте его там, где его увидите вы и исполнитель.

Частые вопросы

Сколько времени занимает такая приёмка?

Проверка сценариев и плохих входов занимает один-два вечера. Тест на своих людях идёт два-три дня, но вам в это время почти ничего делать не нужно.

Можно ли проверить платёж реальной картой на маленькую сумму?

Я рекомендую не делать этого. Для проверки существует тестовый режим провайдера, и все нужные случаи, включая отказ и возврат, проходятся в нём. Боевой платёж нужен один, уже при запуске, и делает его сам владелец под наблюдением.

Что делать, если ошибка нашлась уже после запуска?

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

Коротко о главном

Приёмка перед запуском держится на шести пунктах: роли, плохие входы, свои люди, тестовая оплата, разные телефоны, копии и откат. После запуска остаётся неделя внимательного наблюдения. Как устроена разработка ботов под ваш бизнес, можно посмотреть на странице разработки Telegram-ботов.

Если у вас уже готов бот или сайт и вы боитесь пускать его к клиентам, напишите мне в Telegram с кодовым словом «ТЕСТБОТ». Я пришлю чек-лист приёмки под ваш проект и подскажу, что проверить в первую очередь.