Home

Автор: Сумиа Мухерджи (Soumya Mukherjee)
Оригинал статьи: Tea-Time With Testers, #02/2021
Перевод: Ольга Алифанова

Хоть и немногие в это верят, QA всегда было отдельной специальностью: этот безусловный факт только подтверждается с годами. Даже самые лучшие разработчики не способны тестировать – они или забывают про критические сценарии, или оставляют интеграционное тестирование тестировщикам. QA – неотъемлемое требование для продукта, оно поддерживает все процессы и борется за качество. Во всем мире QA специализировано, и дабы это доказать, посмотрим, сколько проблем вызовет проверка, что чатбот хорошо работает: это требует глубокого понимания работы чатбота, его внутренней кухни, инструментария, алгоритмов, а также генерации сценариев, чтобы все это проверить.

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

Большая часть тестирования современных чатботов – это ручное тестирование черного ящика, в ходе которого тестировщики проверяют:

• Сложные переговоры с пользователями.
• Болтовню вроде «Любишь ли ты людей?» или «Расскажи анекдот».
• Резервные действия для ситуаций, когда чатбот не может с чем-то справиться.
• Интеграции с API, базами данных, голосовыми сервисами, и т. д.

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

В результате в 90% случаев бот ломается, и никто не знает, когда это произойдет – по большей части он просто зависает.

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

• Одна из ключевых проблем – это поддерживание непрерывного разговора по мере развития бота. Боты должны разговаривать, как люди, а QA ограничены в возможности создания или сбора данных о поведении людей.
• Инструменты для управления покрытием стори отсутствуют, поэтому тестировщики даже не знают, что каких-то стори не хватает, и тестируют на одном и том же наборе данных.
• Обучающие данные могут не соответствовать новым стори (полноценным диалогам пользователя с ботом), что приводит к использованию протухших данных. В большинстве случаев для обучения моделей не используются боевые данные, а это ведет к неточным результатам и заиканию бота.
• Большинство инструментов тест-автоматизации способны только на запись и воспроизведение, и тестируют из раза в раз одни и те же стори, что приводит к парадоксу пестицида – в результате бот всегда падает при новом наборе данных и сценариев.
• В QA есть распространенная проблема – отсутствие централизованной информационной панели. В контексте чатботов – отсутствует общая информационная панель, фиксирующая:
  • Соответствие намерениям.
  • Проверку, заполнены ли слоты, в рамках тестирования сущностей.
  • Валидацию сущностей.
  • Проверку уровня уверенности модели, когда выполняется тест.
  • Матрицу неточностей, куда записываются значения метрик Precision/Recall и метрика F1.
  • Бот непросто перезапустить, и если это не удается, бот зависает в ходе разговора.
  • Тестирование мультиязычного бота – это очень трудно, в большинстве случаев приходится создавать двух разных ботов.
  • Если копнуть глубже, окажется, что при наличии высокого уровня уверенности бот будет предсказывать одно и то же для множества намерений, всегда выбирая вариант с высоким уровнем уверенности.

Итак, встает вопрос, как же убедиться, что бот никогда не сломается? Ниже – ряд способов эффективного тестирования вашего бота.

• Очень важно пополнять тренировочные данные боевыми данными. Если этого не делать, бот будет обучаться на старых, оторванных от контекста данных для новых сценариев.
• QA должны всегда создавать как сценарии «счастливого пути», так и сценарии, содержащие контекстно-зависимые вопросы, отклонения от темы, специфичные для отрасли вопросы и бесцельные разговоры.
• QA должны проверять, соответствуют ли сущности сценариям. К примеру, если рассматривается сценарий школьных тарифов, бот не должен брать сущности для автобусных или любых иных тарифов.
• Автоматизированные тесты, в основном на уровне API, должны использовать все стори и прогонять их при каждом регрессе. Их можно получать как напрямую из файла тем (Stories.md в Rasa), так и из репозитория, где они хранятся.
• Визуализация покрытия стори должна всегда быть частью прогона тестов – это ярко демонстрирует прогресс тестирования и процент достигнутого покрытия. Инструментов покрытия историй не существует, но можно подключить графическую базу данных вроде neo4j, хранящую стори, а затем каждый раз проходить по всем узлам, прогоняя стори через бота.

• Большинство компаний не пользуется платформой эмуляции бота для ручного тестирования, но можно воспользоваться инструментами вроде RasaX или BotFront, чтобы визуализировать выполнение, даже если бот еще в разработке.
• Очень важно проверять точность модели для каждого разговора, а затем создать паттерн, чтобы понимать взлеты и падения модели, а также
  • Уровень уверенности.
  • Матрицу неточностей, куда записываются значения метрик Precision/Recall и метрика F1.
  • Кумулятивный профиль точности.
  • Результаты кросс-валидации.
  • Необходимо провести исчерпывающее тестирование устойчивости бота в рамках общего плана QA.
  • Также потребуются интеграционные проверки для внешней базы данных, сервисов, и, что самое главное, всех веб-хуков.
  • Необходимо тестирование толерантности к проблемам в форме тестирования производительности и проверки времени отклика бота, а также менеджмент сессий. В большинстве случаев время отклика бота увеличивается до недопустимого при больших объемах данных, и сессия переполняется, что приводит к падению всей инфраструктуры.
  • Если у вас живая поддержка, то надо проверить установку соединения и передачу данных по маршруту.
  • Важный аспект, про который часто забывают – различные виды тестирования безопасности. В ходе оценки безопасности боты склонны выдавать множество информации о пользовательских данных, и это нужно проверить. Следовательно, требуется анализ безопасности API, а также проверка скорости печати, пунктуации и опечаток.

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

• Масштаб активности.
• Процент отказов.
• Процент удержания.
• Количество открытых сессий.
• Время сессий (длину разговоров).
• Переключение между несколькими стори в длинных разговорах.
• Процент достижения цели.
• Обратная связь пользователей (полезна для анализа тональности высказываний).
• Процент возвратов (уровень неточностей, перезапусков, и переходов на ручное управление).

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

Обсудить в форуме