Снижаем нагрузку на отдел тестирования, расширяем парк устройств и географию тестов, не разоряясь при этом.
Меня зовут Святослав, в IVI я отвечаю за бета-тестирование. Хочу рассказать вам про то, как пользователи могут сделать мир лучше.
У нас в компании есть практика random coffee: сотрудники разных отделов получают приглашение и встречаются в офисе или в Slack, заваривают себе капучино или ванильный макиато и рассказывают друг другу, чем они занимаются. Так мы создаём взаимосвязи и делимся знаниями. И на таких встречах, услышав про бета-тестирование, мне часто задают вопросы: «В смысле? Как? Почему?» Так за многими выпитыми чашками кофе и родился подробный рассказ о нашей работе, про которую, оказывается, не знает никто, кроме нашего клуба бета-тестировщиков и сотрудников тех. отдела. Усаживайтесь поудобнее, наливайте чай, кофе, смузи или апероль шприц.
Программа бета-тестирования существует в IVI с 2016 года. Я пришёл в неё в 2018-м, до этого у меня был некоторый опыт обучения сотрудников и работы с аутсорс-разработкой, а также понимание, как налаживать процессы в компании. Уже тогда IVI был крупнейшим в стране онлайн-кинотеатром на рынке легального профессионального видеоконтента — сейчас у нас 50 млн уникальных пользователей в месяц. Это накладывает обязанность поддерживать огромное количество платформ, от мобильных устройств до любых приставок и Smart TV. К тому же мы транслируем на всей территории РФ и СНГ, в Европе и даже в США, что влечёт и большие технические сложности, в том числе в тестировании:
регрессы на большом количестве устройств;
проблемы синхронизации при тестировании кроссплатформенных функций;
нехватка тестовых устройств;
огромный парк поддерживаемых устройств;
и многое другое.
Как бы вы решали все эти проблемы? Например, наняли больше людей, использовали фермы устройств, всё автоматизировали? Решения хорошие и правильные. Допустим, вы пришли с этими предложениями к руководителю, допустим, он с ними согласился, но запланировать их в бюджет получится только на следующий квартал или даже год. Соответственно, время на реализацию увеличивается в N раз. Мы регулярно увеличиваем бюджет на тестирование: открываем новые вакансии, автоматизируем и внедряем фермы устройств. Но деньги — не единственное и не всегда лучшее решение.
Первые попытки
План был максимально прост: ищем людей, даём им бета-версию и ссылку на описание, объясняем, как создавать отчёт об ошибках. Человек пользуется сервисом, находит ошибку, оформляет отчёт, отправляет на почту. Всё просто и понятно.
Что мы получили в итоге? Если вы пользовались нашим сервисом, то наверняка открывали главную страницу на мобильном устройстве или на сайте, переходили в раздел «Продолжить просмотр» и запускали последнюю серию или фильм, который вы еще не досмотрели. Это самый распространенный сценарий. Пока человек пользуется так нашим сервисом, он может и не столкнуться с ошибками. Поэтому от пользователей, установивших тестовую сборку, мы получали либо ответы «Всё замечательно, от моих трёх действий ничего не сломалось», либо «Всё пропало, ничего не работает» — когда пользователь действительно находил ошибку.
Но даже если пользователи находили баг, никаких подробностей о нём нам не сообщали, потому что люди успевали забыть, как правильно оформлять отчёт — и хорошо ещё, что они помнили почту, на которую нужно писать. К тому же многие подобные сообщения оказывались неактуальными, потому что пользователи могли столкнуться с ошибкой, которую выкатили месяц назад, и к тому времени мы уже сами успели еë найти и поставить в график исправлений.
Главные проблемы с первыми бета-тестировщиками выглядели так:
писали с задержкой;
не сообщали подробностей;
мы тратили много времени на уточнения;
люди быстро забывали об участии в программе бета-тестирования.
Можно было бы сказать, что наша задумка не удалась, закрыть программу и вернуться к традиционным решениям. Но мы очень любим анализировать и работать над ошибками. Поэтому пересмотрели процесс еще раз и составили стратегию, которая исправила бы положение. В любой стратегии сначала нужно сформулировать причину и цель. Причина — у нас не хватает ресурсов для тестирования всех функций на огромном парке устройств. Цель — ускорить тестирование, хотя бы в мелочах, уменьшить нагрузку на тестировщиков и быстрее доводить фичи до релиза.
Стратегия
Мы подумали, что нужно сделать, чтобы пользователи сами как можно скорее писали нам об ошибках. Составили для себя такой список задач:
познакомить с продуктом;
объяснить, чего ожидать;
создать причину для общения, чтобы люди не забывали о программе;
стать частью их жизни;
быть красавчиками.
Два последних пункта я объясню ниже, но, забегая вперёд, скажу, что речь идёт про стиль общения с пользователями, про нашу реакцию на их отчёты (именно реакцию, а не молчаливый сбор сообщений об ошибках).
Изменения
Идеи для изменений принесла практика стажировки в других командах. В первую очередь мы использовали методы и инструменты регрессионного тестирования.
Раньше мы просто давали сборку и говорили: «Вот бета-версия, пользуйтесь». Теперь вместе со сборкой участникам доступны пошаговые инструкции. Например, сразу говорим, в каких функциях исправили ошибки, в каких изменили последовательность действий пользователей, в каких изменили интерфейс, и так далее. И дело не только в дополнительной проверке, а в том, что таким образом мы подталкиваем бета-тестировщиков туда перейти, напоминаем о какой-то функциональности. Попутно человек может заметить то, что мы пропустили.
Кроме того, у многих пользователей несколько устройств, на которых они могут тестировать. Скажем, получив инструкцию об изменениях на телефон человек потом открывает наш сервис на телевизоре или приставке и замечает, что на разных устройствах какая-то функция выглядит или работает по-разному, или вообще отсутствует. То есть получается кроссплатформенное тестирование. Этот подход будет полезен компаниям, в которых разные команды пишут приложение или сервис под разные платформы.
Таким образом мы закрыли пункты стратегии «познакомить с продуктом» и «объяснить, чего ожидать».
Теперь нужно «создать причину для общения». Выше я упоминал про стажировку в других командах, так вот, она помогла мне ближе познакомиться с периодичностью попадания задач на тест и понимать, в какие моменты тестировщикам особенно актуальна помощь. Регулярная сложная задача для тестировщиков — это регрессионное тестирование, поскольку с ним связан огромный объём рутинных работ. Мы воспользовались регулярностью этой задачи и решили писать пользователям как минимум каждый регресс. В результате сегодня мы везде, где можно, запускаем тестирование бета-версии параллельно с регрессом. Если после него что-то исправили, то при отправке в эксплуатацию дополнительно отдаём бета-тестировщикам новую версию с описанием, что мы изменили и что стоит проверить на их устройствах. Коммуникация с участниками бета-теста стала регулярной и обратную связь мы получаем на этапе регресса.
Расскажу небольшую историю из жизни. По сложности у нас особняком стоит Smart TV, потому что в этом сегменте устройств есть несколько производителей, которые каждый год переписывают свои операционные системы. Их приходится регулярно тестировать — по отдельности, а иногда и одновременно, потому что бывает, что даже устройства одного года выпуска имеют критические отличия. Один из бета-тестировщиков работал в магазине телевизоров, и сложно передать, как были счастливы ребята из команды Smart TV: он мог на своей работе проверить наш сервис на любом телевизоре, от самых древних моделей до новейших, которые в магазины попадают гораздо раньше, чем к нам. И даже после того, как этот человек ушел на повышение и перестал работать в магазине, он продолжал распечатывать задачи на тестирование, приходил в магазин и просто проверял на нескольких топовых устройствах, всё ли работает правильно. Миша, огромное тебе спасибо!
Кроссплатформенное тестирование
Выше я говорил про разработку в кроссплатформенных командах, с этим связано несколько сложностей. Во-первых, одна и та же фича делается на разных платформах в разное время, и техническое задание может успеть измениться: например, после версии под мобильные устройства решили что-то пересмотреть, на Smart TV внедрили это изменение, а на мобилках забыли, или наоборот. В этих ситуациях нам помогает кроссплатформенное сравнение с помощью бета-тестировщиков.
Вторая сложность связана с фичами, которые должны одновременно выгружаться на всех платформах. То есть все команды должны быть готовы вместе тестировать какую-то функциональность. Это повышает нагрузку на наших тестировщиков и заставляет откладывать какие-то задачи. Зато можно сгладить ситуацию, отдав бета-тестировщикам какие-то сборки гораздо раньше, даже на этапе ветки. То есть мы можем находить и начинать исправлять ошибки ещё до того, как тестированием займутся наши штатные тестировщики.
Многочисленные бета-тестировщики могут обнаружить и описать те неучтенные ситуации, которые мы просто не можем себе представить или воспроизвести в рамках офиса и доступных устройств.
Идём дальше
После решения проблем кроссплатформенного тестирования мы перешли к ошибкам, требующим дополнительного исследования, исправлять которые — задача не слишком приятная, потому что никогда точно не знаешь, сколько времени займет анализ и что ты получишь в результате. Это и плавающие ошибки, которые могут зависеть от разных факторов; и обращения в техподдержку без пояснения, как воспроизвести ошибку; и актуализация технического долга, который мы, скорее всего, уже закрыли, но у нас нет времени на то, чтобы всё ещё раз проверить.
С помощью бета-тестирования мы проработали такие сценарии:
ошибки при восстановлении пароля;
тест показа ошибок в плеере;
исследование плавающих ошибок;
актуализация старых проблем;
оплата через SMS, PayPal и Банковскими картами;
Расскажу про исследование ошибки, которая была у нас в версии приложения под Android. Как-то один из пользователей обратился в поддержку и сказал, что приложение не запускается. После этого он больше не выходил связь. Нам нужно было понять, что же могло произойти. Нашли двух бета-тестировщиков, у которых на устройствах действительно воспроизводилась такая ситуация, однако изучить ошибку с помощью логирования мы не смогли, потому что она просто не попадала в логи. В итоге мы определили примерный промежуток времени, когда ошибка появилась в коде, и несколько дней бета-тестировщики перебирали архив сборок за этот период, пока не нашли причину ошибки. Светлана и Владислав, огромное вам спасибо!
Что ещё мы можем делать с помощью наших бета-тестировщиков?
IVI — большая компания, и после того, как мы рассказывали коллегам за чашкой кофе, чем мы занимаемся, к нам стали приходить из продуктовых отделов с просьбой опросить наших бета-тестировщиков, как они относятся к новой функциональности.
Также мы сообщаем нашим коллегам, когда кто-то из тестировщиков натыкается на битые видеофайлы. И заодно у нас получается сравнивать себя с конкурентами, ведь у наших пользователей бывают подписки на разные сервисы. Однажды пришла информация, что наше приложение скачивает фильмы чуть медленнее, чем приложение другого сервиса. Мы решили это проверить, ведь мы постоянно работаем над улучшением скорости передачи контента. Нашли тестировщиков в разных городах России и СНГ, готовых протестировать оба сервиса с условием, что у них будет одно сетевое соединение и один и тот же контент в одинаковом качестве, чтобы находиться в максимально одинаковых условиях.
В итоге мы убедились, что не только не уступаем в скорости, но кое-где и превосходим. Чтобы проверить эту гипотезу без бета-тестировщиков, пришлось бы отправлять несколько человек в командировки или просить их помочь во время отпусков.
Снова о стратегии
Итак, мы создали несколько причин для обращения к нашим бета-тестировщикам. Так как тестирование стало регулярной задачей, бета-тестировщики начали постоянно заходить в Telegram-каналы и багтрекер. Они замечают ошибки, заведенные другими, и начинают их обсуждать и проверять у себя. Плавно это стало одним из их хобби. Так мы закрыли один из пунктов стратегии — «Стать частью их жизни».
А что насчёт последнего пункта нашей стратегии — «быть красавчиками»? Речь о мотивации. Мы даём нашим бета-тестировщикам бонусы, которые могут быть материальными и нематериальными. С материальными всё понятно: пользователи могут тратить бонусы, начисляемые на их аккаунт, для покупки подписки или фильмов. Если нам нужно срочно что-то протестировать, мы всегда можем написать, что даём за это задание бонусы не в конце месяца, а сразу.
Нематериальные бонусы иногда сложнее для восприятия. Один из них — это мерч. Да, его любят. Пока что мы его не продаем, а только дарим нашим бета-тестировщикам. Второй наш нематериальный бонус — приоритет в обратной связи. Если бета-тестировщик сообщает об ошибке, он видит, что она заведена и взята в работу. И позже человек видит, что найденный им баг исправлен в очередном релизе, может проверить, всё ли в порядке. То есть люди понимают, что могут непосредственно влиять на наш сервис, помогать улучшать его.
Резюме
Всё, что я рассказал — лишь небольшая часть сценариев работы с сообществом бета-тестировщиков. Можно развивать программу качественно и количественно, придумывать новые сценарии. Давайте вспомним, чем же бета-тестировщики нам помогают:
Мы ускорили получение обратной связи. Раньше на это мог уйти месяц, а сейчас — 1-3 дня.
Мы контролируем единообразие продукта при несинхронной разработке функциональности.
Мы расширили количество устройств до невероятных масштабов.
Помимо проверки боевой и бета-версии:
можем тестировать функциональность на стадии веток,
искать способы воспроизведения ошибок,
актуализировать технический долг.
Инструменты
У нас есть отдельная система мониторинга ошибок — баг-трекер. Она не только помогает отслеживать, на каких устройствах и как мы проверяли свой сервис, но и упрощает исследования: один человек заводит ошибку, а другие могут актуализировать её и дополнить какой-то информацией.
Для опросов мы используем Google-формы, если не требуются групповые исследования, а достаточно получить лишь некую подборку проверок на разных устройствах или обратную связь о функциональности.
Ещё мы очень активно используем Telegram-чат. Иногда бета-тестировщики пишут сначала туда, чтобы уточнить, воспроизводится ли ошибка у других, прежде чем заводить тикет. Полезный инструмент, помогающий быстро что-нибудь проверить.
Герои бета-тестирования
Намеренно на финал оставил рассказ о самих бета-тестировщиках. Прежде всего, это люди, и они классные. Мы не отсеиваем по возрасту, полу, или техническим навыкам. Даже если человек далёк от ИТ, он может включить телевизор и проверить наше приложение. Наши бета-тестировщики — люди с разными взглядами, подходами и ценностями. И благодаря этому разнообразию мы получаем гораздо более обширную обратную связь. Порой люди готовы помогать даже не сервису, а конкретно мне. Например, один бета-тестировщик предложил помощь по вычитыванию опросов, которые я отдавал ребятам, потому что она по роду своей работы этим занимается и может подсказать, что и как лучше отредактировать. Ольга, огромное тебе спасибо!
Ключи к успеху
Что помогло нам добиться всех этих результатов?
Всегда найдётся человек, готовый помочь, нужно лишь попросить. Люди по природе своей хотят делать мир лучше и помогать друг другу.
С людьми нужно общаться, и с пользователями, и с коллегами. Это всегда полезно.
Постоянство — залог успешного взаимодействия. Если человек о вас забыл, значит, вы давно ему не писали и не просили помочь.
Доверие обеспечивает скорость и надежность. Это проверено не только нами.
Люди и время — это ценнейшие ресурсы.
