«Мы стремимся улучшить наш продукт и обеспечить обучение на высшем уровне, а лучший способ добиться этого — самим стать активными пользователями Duolingo. Расскажем, как мы это делаем с помощью процесса, называемого dogfooding.
Догфудинг
Термин «dogfooding» возник после случая с эксцентричным руководителем компании-производителя корма для животных Kal Kan, который на собрании акционеров съел банку собачьего корма, доказывая, что он является потребителем своего продукта, а не просто продает его. Мы тоже учимся в Duolingo и проводим много времени в приложении, тестируем фичи, ищем баги и оцениваем пользовательский опыт.
Как это работает
Сотрудникам Duolingo рекомендуется загружать последнюю внутреннюю версию приложения — Android, iOS или веб-клиенты (или все три) — и регулярно пользоваться ею. Это последний билд приложения, и мы тестируем новые фичи до того как они попадут к пользователям.
В Duolingo руководство активно поощряет догфудинг, привлекаются все, а не только те кто непосредственно создает фичи. На данный момент более 70% сотрудников вовлечены в процесс, не исключая и генерального директора компании, который каждый день проходит курсы на разных девайсах.
В дополнение к стимулированию культуры догфудинга на всех уровнях компании, проводится внутренний челлендж по языкам, и его участники, учившие язык полгода без перерыва, получают премию. Эти сотрудники предоставляют ценный фидбек.
Метрики
После выхода нового билда сотрудникам Duolingo рекомендуется загрузить его и начать тестировать, чтобы начать сбор телеметрии. В первую очередь это метрики производительности, события App Not Responding (ANR), креши, события Out of Memory (OOM), а также метрики частоты кадров. В Duolingo используется Google Firebase Crashlytics для сегментирования данных о сбоях по клиентам и версиям.
Мы получаем так много данных, что пришлось создать кастомные инструменты для быстрых инсайтов из телеметрии и масштабирования инженерных операций.
Для метрик производительности мы создали специальный Release Dashboard, показывающий телеметрию новых сборок, как только они попадают на внутренний догфудинг. Мы получаем инсайты в течение нескольких часов.
Release Dashboard с метриками производительности iOS-сборки
Это позволяет инженерным командам отслеживать производительность следующих релизов и, если метрики нехорошие, исследовать проблемные места и запускать регрессии.
Также мы создали внутренний инструмент Jeeves, который аккумулирует отзывы из баг-репортов нашей бета-программы, а также отзывов на внешних площадках: Reddit, Twitter, Google Play и App Store, а также Zendesk.
Jeeves при помощи ИИ группирует эти данные по ключевым словам и типичным фразам.
Мониторинг багов в Jeeves
QA и dev-команды разбирают «всплески» ключевых слов в репортах, что позволяет заблаговременно выявлять, сортировать и устранять проблемы.
Репорты
Инженерные команды получают большую пользу от фидбека сотрудников. Чтобы упростить процесс заведения и разбора багов, мы создали еще один внутренний инструмент под названием Shake-to-Report, который позволяет сотрудникам быстрее репортить баги.
Shake-to-Report работает так же как звучит: если сотрудник замечает баг, он встряхивает девайс (или на веб-клиенте нажимает кнопку), и репорт отправлен.
В репорт автоматически включается скриншот и метаданные: название фичи, версия девайса и приложения, курс и урок.
В баг-репорт также включается запись Fullstory, которая показывает, что пользователь делал до того как случилась ошибка.
Баг-репорты в Shake-to-Report также содержат лог-файл для отладки соответствующей инженерной командой.
Например, перед запуском курсов по математике и музыке в приложении для iOS сотрудники Duolingo в течение нескольких месяцев тестировали внутреннюю сборку этих курсов. За несколько недель до официального запуска команда, работающая над курсом «Музыка», зафиксировала постоянные сообщения о сбоях от наших догфудеров, а также повышение количества сбоев в Crashlytics.
Креши в курсе Музыка
Для диагностики этих сбоев команда добавила дополнительную детализацию в логи, ориентированную на данные о курсе Music, данные о песнях, и взаимодействиях пользователей с этим курсом. Баг-репорты продолжали поступать, команда проанализировала логи и выявила главную причину проблем. Это был edge case, возникающий на паузе песни при определенной последовательности нажатий.
До запуска курсов «Математика» и «Музыка» на iOS оставалось всего несколько недель, но благодаря нашим сотрудникам-догфудерам все было исправлено вовремя.
Релизы
Инструменты Release Dashboard, Jeeves и Shake-to-Report создаются и поддерживаются выделенной командой — Test and Release Infrastructure team, которая тесно сотрудничает со службой поддержки и QA-отделом.
По понедельникам с утра, перед релизом новой публичной версии приложения, наш QA-отдел разбирает баги, о которых сообщалось на выходных нашими догфудерами. Развертывание задерживается, если обнаружены блокеры или баги, существенно влияющие на user experience; менее приоритетные передаются QA-команде.»
