Впевнена відповідь не означає, що запис відбувся
Бот може з повною впевненістю сказати «ви записані, чекаємо в четвер о 3 годині дня», а запис нікуди не потрапить: стиліст так і не отримав сповіщення, вікно не заблокувалося в календарі або повідомлення потрапило в тестовий чат замість справжнього. Текст відповіді доводить лише те, що бот уміє складати слова, а не те, що на іншому кінці щось справді сталося. Перевіряти треба результат, а не розмову: чи з'явився запис там, де його побачить стиліст.
П'ять сценаріїв, які варто пройти самому
Недостатньо пройти один ідеальний шлях: вибрати час, підтвердити, отримати відповідь. Принаймні п'ять сценаріїв пройдіть так, як їх проходили б різні справжні клієнти:
- Ідеальний шлях: вікно вільне, клієнт обирає його й підтверджує.
- Зайняте вікно: клієнт намагається обрати вже зайнятий час, бот має запропонувати інший, а не зависнути.
- Скасування й перенесення: клієнт скасовує чи переносить наявний запис, вікно має звільнитися чи переміститися в календарі, а не продублюватися.
- Неповні дані: клієнт вводить ім'я без телефону або кидає розмову на півдорозі, бот не повинен створювати запис із пропуском.
- Екран телефона: та сама розмова на малому екрані, кнопки й текст не мають обрізатися чи накладатися.
Перевіряйте місце призначення, а не розмову
Після кожного тесту подивіться, де запис мав опинитися насправді: у календарі стиліста, у таблиці чи в чаті, де сповіщають персонал. Чи збігаються час, ім'я й телефон у цьому записі з тим, що ввів тестовий клієнт. Якщо бот сповіщає стиліста, переконайтеся, що сповіщення справді дійшло, а не лише що сценарій мав його надіслати.
Ведіть список розбіжностей замість латання на льоту
Кожну знайдену розбіжність варто записувати: що очікувалося, що сталося насправді, а після виправлення цей самий сценарій тестують знову. Латання «на льоту» без списку майже завжди означає, що та сама помилка повернеться за місяць, бо щось виправили правильно, але не той випадок, який справді зламався.
Тестуйте там, де буде клієнт, а не лише в панелі розробника
Розмова, яка виглядає правильно в тестовій панелі бота, може поводитися інакше в реальному каналі: Telegram, WhatsApp або віджеті на сайті, куди вбудовано бота. Остаточну перевірку слід робити в тому каналі й на тому пристрої, якими користуватиметься справжній клієнт, а не лише в середовищі розробки.
Типові помилки, коротко
- Тестують лише ідеальний шлях, без зайнятого вікна й скасування.
- Сповіщення стиліста перевіряють за логікою сценарію, а не за реальною доставкою.
- Тестують у панелі розробника, а не в справжньому чаті на телефоні.
- Помилку виправляють, але той самий сценарій більше не тестують, щоб підтвердити.
Чек-лист перед запуском
- [ ] Протестовано ідеальний шлях, зайняте вікно, скасування чи перенесення, неповні дані та екран телефона
- [ ] Кожен тестовий запис знайдено в справжньому календарі чи таблиці персоналу
- [ ] Сповіщення стиліста підтверджено реальною доставкою, а не лише логікою сценарію
- [ ] Вели список розбіжностей і закривали його повторним тестом, а не лише виправленням
- [ ] Останній тест пройшов у справжньому каналі й на справжньому пристрої клієнта
Що можна доручити нам
Перевірка й виправлення бота входить у план підтримки студії, від $150 на місяць. Також можна обговорити з нами тестування вашого бота для запису.
