Качество — на первом месте: разработка и тестирование устройств с Алисой

Hardware-разработка и производство устройств

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

• Дизайн → как должно выглядеть устройство
• Конструирование → какие инженерные решения нужно использовать

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

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

Тестирование на производстве

У нас есть Chamber — специальный ящик, через который проходит каждая колонка в процессе производства.

Внутри Chamber стоят камеры и микрофоны. На колонке прогоняются тесты, автоматика проверяет, что корректно работает LED-подсветка, звук и прочее.

Нюанс в том, что сам процесс тестирования может выйти из строя. Мы это предусмотрели, поэтому рядом с Chamber стоят колонки, с которыми точно всё в порядке. С их помощью можно проверить, что сам Chamber работает корректно.

Помимо Chamber, Яндекс Станции Миди мы проверяем в специальной нагрузочной комнате. Она достаточно большая, в ней повышена температура. В конце комнаты ставят колонки, которые сходят с линии, и запускают звук на максимальной громкости. Если под нагрузкой всё работает как надо, то колонка уходит в продажу.

Стандарт в индустрии при производстве hardware устроен так: если брака меньше 2% — считается, что партию можно отправлять в продажу. Но нам не нравится идея, что какие-то бракованные устройства могут попасть в дома пользователей. Поэтому мы наладили наш процесс тестирования так, чтобы отлавливать все возможные проблемы. Сейчас их порядка 0,5% на производстве — эти устройства не уходят в продажу и не попадают к пользователям.

Качество software внутри колонки

Чтобы колонка «ожила», внутри неё должен быть какой-то код — embedded software. Мы не ограничиваемся тем, что пишем код в прошивку и отдаём на завод. Наши прошивки обновляются еженедельно — и для того, чтобы выкатывать новые продуктовые фичи, и чтобы улучшать качество устройства.

Наш релизный процесс занимает почти три недели, а релизы выкатываются каждую неделю — они накладываются друг на друга. Сам процесс устроен так:

• В системе контроля версий отводится релизная ветка, происходит сбор релиза.
• Начинается основное тестирование — ручное и автоматизированное, делаем фикс релизных багов.
• Происходит раскатка на бету и на 1% продакшена. Бета — внутренние пользователи Яндекса, которые участвуют в бета-тестировании. На 1% — это A/B-эксперимент, чтобы отследить все метрики на минимальной выборке.
• Убеждаемся, что на 1% пользователей нет проблем, и выкатываем на 10%, чтобы иметь в эксперименте больше данных и увидеть потенциальные ошибки, которые не были видны на одном проценте.
• Раскатываем релиз на всех пользователей.

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

Эти колонки не совсем обычные: в каждую припаяна специальная кнопка, которая хардварно отключает динамики. Ферма стоит у нас в опенспейсе, и, если во время тестов оставлять динамики включёнными, рядом с ней невозможно будет работать.

Тестирование software на бэкенде

Чтобы Алиса работала в колонках, Алиса должна работать ещё и на бэкенде — там происходит распознавание речи, диалоговый движок и синтез.

Продукт Алисы состоит из трёх компонентов:

• ML
• Продуктовый код
• Инфраструктура

Мы считаем, что в Алисе, как и в Яндексе в целом, ML-систему нельзя просто сделать и забыть о ней. Поэтому постоянно работаем над улучшением распознавания речи, классификации сценариев и синтеза речи.

Однажды мы откатили качество синтеза речи в A/B-эксперименте на год назад и получили множество жалоб в техподдержку — пользователи думали, что у них сломалась колонка. Такой опыт помог убедиться, что мы всё делаем правильно и над улучшениями нужно продолжать работать всё время.

Продуктовый код сильно зависит от того, на каком устройстве работает Алиса. Есть разные мультипликаторы:

• Более 10 разных колонок
• Более 5 приложений
• Яндекс ТВ Станция и другие телевизоры с нашей прошивкой Яндекс ТВ
• Голосовой помощник в мультимедийной системе Яндекс Авто
• Несколько языков, на которых наши технологии умеют работать

Большое количество операторов условий в продуктовом коде по-разному себя ведут в зависимости от того, где Алиса работает.

Здесь мы также используем ручное тестирование, но в меньшем объёме, и в первую очередь полагаемся на автоматику:

• Evo-тесты — функциональные тесты. Разработчики на Python пишут сценарии взаимодействия с Алисой от лица какой-нибудь платформы. Помимо кода самого теста, есть ещё небольшой симулятор устройства, который знает об изменении состояния устройства и умеет правильно пересылать его в сценарии. Например, при запуске музыки перед следующим запросом устройство должно отправить отчёт, что играет такой-то трек, — чтобы его можно было перемотать или спросить, кто исполнитель.
• Ue2e-прокачка — тестирование вариативности ML, который есть в Алисе. Здесь мы отправляем множество запросов с разными сценариями, которые система должна обработать. Они нужны, чтобы проверить, что вариативность ML не поменялась. На каждом релизе задаём несколько тысяч запросов в систему и проверяем, что на них всё работает так, как мы хотим. Есть асессоры, которые отсматривают результаты работы системы и определяют, «уместный» ответ или «неуместный».