Привет, Хабр! Меня зовут Оля, и я работаю QA-инженером в команде лингвистов Just AI. Для лингвистов-разработчиков каждый чат-бот — это отдельный проект со своими фичами, иногда с собственным характером и всегда — с особым подходом к тестированию. В тестировании ботов, помимо проектной специфики (a.k.a. конкретные требования и «хотелки» заказчика), которую обобщить едва ли возможно, есть еще и неочевидные вещи, связанные со спецификой самого типа бота. В этом материале я постаралась аккумулировать наш опыт запуска голосовых и текстовых ботов в продакшен (десятков ботов!) и собрать рекомендации о том, как их тестировать.
Сразу отмечу, что я хочу обратить внимание именно на специфические для разных типов ботов аспекты. Соответствие бота ТЗ, корректную работу сценария и API, понимание ботом естественной речи — все это, конечно же, тоже нужно тестировать (и мы это делаем 😊), но сейчас речь пойдет о менее очевидных, но не менее важных вещах, от которых зависит качество финального продукта.
Начнем с голосовых ботов
Основная проблема голосовых ботов, которая часто является причиной неприятных багов — это использование технологий ASR и TTS.
Несмотря на динамичное развитие технологии ASR (Automated Speech Recognition), качество распознавания остается несовершенным, особенно в условиях внешнего шума, помех или из-за индивидуальных особенностей речи пользователя (плохая дикция, шепот, картавость и т.д.). Если ASR подводит, то реально озвученный запрос не совпадает с его текстовым вариантом, соответственно, эта неверная расшифровка будет в итоге классифицирована в системе как баг.
Ошибка возникает, потому что такой вариант не связан семантически с предусмотренным — он не занесен в паттерны бота или в примеры тренировочных фраз для NLU-классификатора. Сложно предугадать, что под фразой «стоит мельница» будет маскироваться простой вопрос «что изменится», а «дата за свидание» — это на самом деле «да, в Казахстане». В нашей практике было настолько много случаев невероятного распознавания, что мы даже решили завести отдельный канал, чтобы делиться находками.
Шутки-шутками, но как же быть с такими багами? Вносить все такие случаи в паттерны? Потенциально это может сломать логику бота. Совсем игнорировать? Тоже не годится, ведь мы хотим, чтобы бот понимал пользователя с первого раза.
Ну и как быть?
Мы придерживаемся следующего подхода. Тестировщик проверяет бота голосом и отслеживает в логах диалога те места, где бот не понял его запрос или повёл разговор не по сценарию. Логи показывают, где ошибка произошла именно из-за некорректного распознавания – мы говорили одно, а бот определил другое. Тестировщик решает, какие варианты распознавания могут быть занесены в сценарий на благо пользователю и не во вред логике бота.
Важно! Если некорректно распознанная форма совпадает с паттерном в другом стейте, то лучше ее не добавлять.
Возьмем простой пример для наглядности. У нас есть игра, где в качестве персонажа можно выбрать верблюда, козла или осла. Мы тестируем игру и случайно «осёл» распознается ASR как «козёл». Очевидно, что мы не будем добавлять в варианты паттернов для сценарной ветки «осел» слово «козел», так как это приведет к ложному срабатыванию. А вот если тестировщик сказал «хочу играть за верблюда», а из-за внешнего шума или помех ASR распознал «хочу играть за блюдо», то добавив «блюдо» в ряд синонимов к «верблюду», мы не нанесем вреда логике сценария, а даже напротив, вероятно, спасем пользователя от ответа «Извините, я вас не понял, повторите, пожалуйста».
Еще одна хорошая практика – если в сценарии предполагается употребление пользователем сложных или редких слов, аббревиатур или других единиц, которых может не быть в словаре, то им нужно уделить особое внимание. Можно «понаговаривать» их несколько раз – чуть быстрее или медленнее, с разной интонацией и т.п., чтобы выявить частотные варианты некорректного распознавания и внести их в бота.
Пример из практики Just AI:
В проекте голосового бота для Росконгресса использовались много редких иноязычных слов, а также уникальных названий, которых нет в словаре: например, "бейдж", "кейтеринг", "Росконгресс", "лаборатория Инносоциум" и другие. Для ASR распознавание этих единиц - непростая задачка. Но решить эту задачу было очень важно - ведь для многих вопросов, ответы на которые должен был давать бот, эти сложные слова были ключевыми - например,"где получить бейдж", "в какие дни работает лаборатория инносоциум". Если мы не поймаем эти ключевые слова, то не уловим суть вопроса, поэтому нам нужно было научить бота понимать как можно больше вариантов того, как эти слова могут быть распознаны. В итоге в паттерны для этих слов наряду с обычными синонимами было внесено достаточно много интересных, забавных и неожиданных сочетаний букв и слов.
Чтобы помочь улучшить ASR, мы периодически даем обратную связь поставщикам этой технологии в виде репорта самых частых ошибок. Это полезно для обеих сторон.
Разбираемся с TTS
Другая технология, баги в которой могут сделать звучание бота менее человечным, это TTS (Text to Speech) – преобразование печатного текста в речевой сигнал. Люди, как правило, совсем не толерантны к такого рода ошибкам: неестественно расставленные паузы, неправильные ударения, произношение отдельных звуков в словах и интонация – всё это сразу цепляет слух, выдает бота и раздражает пользователя.
Эти проблемы решаются или сглаживаются средствами разметки синтеза текста. Когда в репликах бота используется технология TTS, тестировщику нужно обязательно послушать, все ли фразы воспроизводятся корректно, чтобы отправить разработчику неестественно звучащие реплики на исправление или доработку. Благодаря средствам разметки синтеза разработчик может изменить звучащую на выходе речь – от постановки ударения и расстановки пауз до придания эмоциональной окраски там, где это необходимо.
Помимо TTS для озвучки бота могут использоваться заранее записанные диктором реплики, которые подгружаются в сценарий как аудиофайлы. Как и в случае с синтезом речи тестировщик обязательно проверяет, что все фразы (т.е. аудиозаписи реплик) воспроизводятся корректно и убеждается, что текст реплики, которую он слышит в боте, соответствует тексту в сценарии.
Тестирование отчетов
Большинство ботов c обзвонами предполагает заполнение отчетов о звонках – это сводные таблицы, в которых содержится информация о каждом диалоге пользователя с ботом. Такой инструмент аналитики полезен не только заказчику, но и нам, ведь отчеты могут содержать не только стандартные поля с временем, длительностью и результатом звонка, а еще и кастомные, в которых фиксируются ответы на конкретные вопросы. Если бот собирает обратную связь о качестве обслуживания в сервисном центре, то в такой отчет он будет записывать оставленные пользователем оценки и комментарии.
Основные задачи тестировщика:
Проверить, корректно ли работает логика заполнения таких отчетов: все ли столбцы заполняются в соответствии с ТЗ.
Продумать пограничные кейсы и то, какими путями пользователь может попасть в один и тот же контекст.
Проверить, что перезатирание переменных в полях происходит корректно (например, пользователь сначала назвал один адрес для доставки своего заказа, а на этапе проверки всех введенных данных решил поменять его на другой. В отчете должен остаться последний вариант).
Переходим к текстовым ботам
При взаимодействии с текстовыми ботами пользователь воспринимает информацию зрительно. Иными словами, он обращает внимание на то, что обобщенно можно назвать интерфейсом бота — это тексты реплик, кнопки, ссылки и т.п. Здесь мы уже немного вторгаемся в пространство UX. Расскажу, на каких моментах лучше заострить внимание при тестировании.
Начнём с того, что есть в любом чат-боте, — это его реплики. При общении в «письменной» форме для многих людей важно, чтобы сообщения собеседника были грамотными.
В случае общения с чат-ботом ожидания пользователя еще выше — ведь бот выводит на экран заготовленные ответы, которые были проверены заранее. Одно сообщение, содержащее грубую ошибку или опечатку, способно подпортить не только впечатление от чат-бота, но и имидж компании, которую он представляет.
Грамотный бот — хороший бот
Чтобы не допустить такой ситуации, все тексты в боте нужно тестировать в рамках общего функционального тестирования. Проверяя сценарные ходы, обращайте внимание на реплики, которые встречаются вам на пути. Еще один лайфхак — ищите и устраняйте ошибки еще на этапе написания и ревью сценария: тогда вероятность того, что опечатка или языковая ошибка перекочует в код ловким движением «ctrl+c – ctrl+v», снижается до минимума.
Помимо очевидных ошибок (орфография, пунктуация, речевые ошибки), можно и нужно проследить за единством стиля написания наименований, которые часто встречаются в репликах. Возьмем в качестве примера название компании Microsoft.
Единство языка написания, использование заглавных/строчных букв, кавычек – это вещи, которым, на мой взгляд, стоит уделить немного времени на этапе тестирования. Конечно, ошибки в этой области не будут критичными, но зато выверенные до мелочей текстовки будут знаком особого качества вашего продукта. Совет из практики – уделите внимание этому аспекту еще на этапе тестирования сценария: в текстовой версии гораздо проще будет зафиксировать и поправить все несовпадения обычной автозаменой, чем потом выискивать их по всему боту.
Мелочь, а неприятно!
Обязательно проверьте отображение списков в репликах, убедитесь, что они не «поехали» или не сбились в одну строку. Кроме того, протестируйте текстовые выделения – как в разных каналах будут отображаться полужирные, курсивные и другие выделения текста, нигде ли нет вкраплений языка разметки или лишних символов.
При тестировании реплик в отдельный блок можно вынести ссылки, которые мы можем встретить в текстовках бота. Остановлюсь на нескольких моментах, которые стоит проверить:
Актуальность: отталкиваясь от контекста реплики, нужно проверить страницу по ссылке – актуальна ли она сейчас, действительно ли по ссылке содержится та информация, которая необходима пользователю.
Кликабельность: гораздо более user-friendly пользователю покажется бот, который позволит переходить на нужные страницу по клику, поэтому по возможности нужно сделать так, чтобы все ссылки были активными.
Отображение длинных ссылок: если ссылка на нужную страницу занимает несколько строчек в реплике бота или вообще создает полотно символов на половину экрана – это, конечно, выглядит не очень хорошо. Длинные ссылки лучше будет скрыть в коротких словах или словосочетаниях («на нашем официальном сайте», «информацию можно найти тут» и т.п.)
Внимание на кнопку
Еще одна особенность текстовых ботов – это наличие кнопок. Может казаться, что бот с кнопками слишком прост – раз есть кнопки, значит бота не довели до ума. Это не так. Кнопки облегчают взаимодействие пользователя с ботом, но что более важно, направляют диалог в нужное русло, помогают быстро переключаться между разными частями большого функционала или разными тематиками.
Первое, что нужно проверить – корректность работы кнопок, их кликабельность и правильный адрес в сценарии. Также советую не пренебрегать правилами хорошего тона – научите бота распознавать не только фразы с кнопок, введенные текстом, но и синонимичные им. Например, если по сценарию выводятся кнопки «да» и «нет», то идеальный бот должен:
Правильно переходить по нажатию на эти кнопки.
Правильно переходить по запросам «да» и «нет».
Правильно переходить по запросам «ок, хорошо, давай» и «не надо, не хочу, неправильно» и т.п. в зависимости от контекста.
Очень много подводных камней таит в себе работа кнопки «назад» – ее реализация достаточно сложная в плане логики. Советую протестировать её из разных состояний и контекстов, убедиться, например, что вместе с предыдущим сообщением бота выводятся и кнопки, которые были к нему прикреплены.
Кнопки «вперед»/«еще»/«далее» встречаются реже, но логика переходов по сценарию в них тоже достаточно непростая. Тестировщик должен убедиться, что эти переходы «вперед» и «назад» работают правильно, что нужные данные сохраняются, а ненужные стираются, когда мы их используем.
И, наконец, «косметический» момент для разработчиков-эстетов – отображение текста на кнопках. Обратите внимание на то, как отображаются длинные названия кнопок в целевых каналах. Возможно, они обрезаются после определенного количества символов, и стоит их сократить, чтобы они помещались целиком.
В принципе проблем с пониманием функционала кнопки с названием «Принять обращ….» не будет. Но может быть так, что сокращенная текстовка вызывает недопонимание, и тогда это повод обратиться к дизайнерам и разработчикам, чтобы вместе изменить ее.
Подводя итоги (наконец-то!)
Итак, в этой (внезапно разросшейся) статье я постаралась обобщить свой разнообразный опыт тестирования голосовых и текстовых ботов, поделилась кейсами и практическими советами, которые, я надеюсь, помогут повысить качество ваших ботов. Для удобства я собрала все самое основное в небольшой чек-лист.
Дисклеймер: пункты в этом чек-листе являются расширением и дополнением для основного процесса тестирования, где мы проверяем соответствие функционала ТЗ (и здравому смыслу) 😊
А на какие неочевидные вещи вы обращаете внимание, когда тестируете ботов? Делитесь в комментариях и let's make bots better together!
