«Расскажу, чем занимается команда WhatsApp — чтобы другие QA-команды по всему миру могли почерпнуть что-то полезное из нашей практики.
Подход
В течение полутора лет, с конца 2021 года до середины 2023 года, я работал в команде Test Automation в лондонском офисе WhatsApp, и мне удалось очень близко, на личном опыте ознакомиться с тем, как тестируется приложение, установленное у более чем 2 млрд. пользователей.
Моя команда Test Automation отвечала за создание тестовой инфраструктуры, инструментов и фреймворков, позволяющих разработчикам писать тесты клиентских приложений WhatsApp (а это не только Android и iOS, но также веб-приложения и десктопные). Это была важнейшая задача нашей стратегии тестирования.
В каком-то смысле подходы WhatsApp вполне стандартные, как у любого другого мобильного приложения, ориентированного на массового потребителя, со всеми обычными уровнями тестовой пирамиды.
Команды в WhatsApp предпочитают использовать инструменты с открытым кодом для написания автотестов, но также создают и применяют довольно большое количество «внутренних» инструментов (далее их называем также кастомными/особыми), созданных ранее в Meta/Facebook; команды работают в гибко настраиваемой инфраструктуре, с целью соблюдения утвержденной стратегии тестирования.
При этом подход к тестированию в WhatsApp существенно отличается от обычного подхода в Meta, то есть в Facebook.
Далее расскажу о двух ключевых аспектах, которые обеспечили у нас высокую культуру автоматизации:
- Фреймворки и инфраструктура
- Специальные команды и разработчики
Тестовые инструменты и фреймворки
Сначала рассмотрим уровни нашей пирамиды тестирования, и какие инструменты и фреймворки использовали.
Что касается мобильных фреймворков, автоматизированные тесты пишутся на всех уровнях тестовой пирамиды; сравнительно много тестов в Espresso и XCUITest; и меньше E2E-тестов.
Android
- Юнит-тесты: JUnit, Roboelectric
- Тесты интерфейса: Espresso
- Скриншот-тесты. (здесь на GitHub код этого инструмента)
- E2E-тесты: Jest-based кастомный фреймворк для сквозного тестирования
iOS
- Юнит-тесты: XCTest
- Тесты интерфейса: XCUI
- Снепшот-тесты: код на Гитхабе
- E2E-тесты: Jest-based фреймворк
Тестовая инфраструктура
Meta предоставляет всю инфраструктуру, девайсы, и CI-инструменты.
Контроль тестового покрытия
- Кастомная инфраструктура сбора данных о покрытии юнит- и UI-тестами
- Кастомные дашборды визуализации трендов и тестовых метрик
Управление версиями
Вот это вполне стандартное:
- Git
- Mercurial
Тест-раннер
- Самописный тест-раннер
Девайсы и эмуляторы
- Парк девайсов и эмуляторы предоставляет Meta
Что по билдам
- Android: Gradle
- iOS: Xcode
- Buck2, фейсбучная внутренняя билд-система, и здесь ее код
Репорты
- Особая инфраструктура логов
- Мониторинг тестов — в Scuba [тоже внутренняя система управления данными, здесь подробнее о ней]
- Также особая инфраструктура репортов
CI
Тоже внутренняя CI-система Facebook (здесь описана)
Тестирование функций (фич)
- Подбор тестов предиктивный, описан здесь
- На основе рекомендаций
- Обезьянье тестирование выполняется в Sapienz (внутренняя система Меты, здесь описана)
- Статический анализ кода в Infer (еще одна внутренняя система Меты, здесь ее Гитхаб)
Читая этот список, можете убедиться, что Meta — это компания с потрясающей инженерной культурой, которая публикует блоги о многих своих внутренних инструментах в открытых источниках и рассказывает о них. Если интересуетесь этим, рекомендую подписаться на наш блог DevInfra, и посмотреть код проектов на GitHub, может быть, какие-то реализации покажутся полезными.
Еще об инструментах и фреймворках
Итак, существует набор стандартных и внутренних инструментов и фреймворков, в большой масштабируемой инфраструктуре Meta. Таким образом, SDET-тестировщикам в Meta нет необходимости тратить время на поддержку инфраструктуры, они работают над своими тестами, будучи уверенными, что всё будет прекрасно работать и масштабироваться, если следовать рекомендуемым практикам.
Вы также могли заметить, что большинство стандартных инструментов используется в других компаниях и стартапах, и часть из них с открытым кодом.
В Meta внутренние инструменты оптимизированы в течение многих лет и хорошо интегрированы друг с другом, создана целостная надежная экосистема. Чтобы разобраться в ней, не требуется длительное обучение.
Рассказ о процессах
Вы ознакомились с инструментами WhatsApp, а теперь, возможно, интересует вопрос, как организованы команды и какое распределение задач.
Кто пишет автотесты
В WhatsApp основную часть автоматизированных тестов разработчики пишут сами.
Они пишут код приложения, а также юнит-тесты, и UI-тесты (интерфейса) и, иногда, некоторые важнейшие E2E-тесты. Ранее я уже выкладывал небольшую заметку об этой практике.
Здесь я имею в виду в первую очередь мобильных разработчиков, поскольку WhatsApp, будучи приложением для общения, ориентирован на мобильных клиентов. Но есть и серверные команды, которые придерживаются похожей философии и тоже пишут свои тесты.
Это хорошо тем, что разработчики несут ответственность за свои тесты (владеют ими), а также отвечают за любые SEV (критикалы и дефекты высокой серьезности). Поэтому они естественным образом мотивированы на написание автоматизированных тестов соответствующего уровня надежности, чтобы продуманно покрыть тестами собственный код и снизить риски.
У нас нет специальных команд QA-автоматизации, состоящих из SDET/SET (Software engineer in tests) , введенных в состав Feature-команд, которые бы занимались только написанием автоматизированных тестов. Хотя такая практика популярна и довольно часто встречается в стартапах и крупных компаниях.
В связи с этим возникают естественные вопросы:
- Каковы позитивные стороны такого подхода?
- А как же инструментарий и инфраструктура? Кто-то должен все это создавать и поддерживать?
- Тесты, написанные разработчиками, более качественные по сравнению с тестами, написанными тестировщиками?
Плюсы и минусы такого подхода
- Одним из преимуществ является то, что пишется много автоматизированных тестов и тестирование очень хорошо автоматизировано.
- Если тесты оказываются некачественными (то есть нестабильными и ненадежными), то тестовая инфраструктура сама позаботится о том, чтобы исключить их из числа выполняемых, и уведомляет об этом автора теста в таск-менеджере.
- Мы считаем, что плюсом является отсутствие отдельной команды именно тестировщиков для написания всех автотестов, которая иногда является «узким местом» в QA-процессах.
- Наши сотрудники не утруждают себя созданием и поддержкой инструментов и инфраструктуры, а просто используют существующие инструменты Meta.
- Нестабильные тесты исправляются быстрее (так как сразу обращают на себя внимание).
- Сотрудники реально внедряют лучшие практики тестирования, и в данном случае лозунг «Качество — это ответственность каждого» воплощается в работающий принцип, а не остается стандартным плакатом на стене.
А есть и минусы:
- В тестах случаются некоторые проблемы с robust assertions (о твердых, или robust assertions — почитать здесь).
- Бывает много дублирующегося кода, из-за того что у нас мало абстракций. Наши разработчики рассматривают написание тестов просто как очередную задачу в своем чек-листе перед отправкой фичи, они не уделяют должного внимания созданию хороших многократно используемых абстракций.
- Создается довольно-таки много нестабильных и избыточных/перекрывающихся тестов.
Инфра-команды создают инструменты и фреймворки
В WhatsApp за создание и поддержку тестовых инструментов/фреймворков отвечают специальные Infra-команды.
В их компетенцию входит комплексная формулировка стратегии тестирования; как вглубь, так и вширь. Эти команды не пишут тесты; они помогают создать достаточный уровень тестовой инфраструктуры и инструментов для поддержки SDET-разработчиков, пишущих тесты.
Они также глубоко переживают и заботятся [так в оригинале.] о качестве приложений и создают решения, облегчающие жизнь разработчикам. Они являются чемпионами и экспертами в области автоматизации тестирования; к ним команды разработчиков обращаются за советом и за кастомными решениями для их задач. Инфра-команды также создают обучающие материалы — внутреннюю документацию и курсы по автоматизации тестирования.
Необходимость создавать такие специальные инфра-команды — совершенно очевидна. У SDET-разработчика, плотно занятого работой над фичами и, далее, их автоматизированным тестированием, практически не остается времени на создание системных решений для тестирования, которые бы хорошо масштабировались. Infra-разработчик не беспокоится о написании тестов и ежедневной доставке разрабатываемых функций, и может сосредоточиться исключительно на создании и поддержке инструментов и инфраструктуры. Поскольку они создают инструменты для многих команд параллельно, это приводит к появлению очень универсальных решений, которые потом могут использоваться в других проектах.
Ключевой момент — наличие понимающего руководства, которое поддерживает такое разделение обязанностей и видит его ценность, обеспечивает продвижение инициатив, и финансирование. Без этого подобная команда не сможет работать продуктивно, и в WhatsApp нам повезло, что за этой практикой стояли сильные лидеры, не боящиеся экспериментировать.
ProdOps-команда обслуживает инфра-команды
Наши Infra-разработчики это опытные инженеры-программисты, некоторые из них ранее работали в качестве штатных разработчиков в мобайле и бэкенде. И — кстати — очень редко они приходили из сферы именно тестирования (не были QA Engineer), в прошлом они почти всегда были разработчиками.
Они знают, как создавать инфраструктуру и инструменты, но не имели глубоких связей с Feature-командами, не всегда понимают все тонкости STLC, и не имели опыта с тестовыми фреймворками и лучшими практиками.
Команда ProdOps — команда, которая восполняет этот пробел. В ней работают инженеры, называемые у нас TQS (Technical Quality Specialists).
Эта команда в некотором смысле похожа на стандартную QA-команду, отвечающую за соблюдение нашей хартии качества по всему продукту. Этой группе также приданы несколько разработчиков Android/iOS.
ProdOps-разработчики отвечают за ряд важных задач:
- Являются экспертами в области исследовательского тестирования и глубоко понимают продукт и его пользовательские пути (flows). Они фокусируются на первоочередных функциях приложения и обеспечивают чтобы все было отлично с точки зрения QA и QC, работая над features в WhatsApp; их компетенция это например WhatsApp-каналы, аватарки и т.д.
- Они оказывают поддержку Infra- и Feature-командам в следующем:
- Выполняют базовый тест-дизайн и предиктивно предлагают тест-кейсы; также определяют их приоритетность (с точки зрения важности).
- Обеспечивают качество тестовых наборов, путем обновления, а также поиска и удаления ставших ненужными тест-кейсов
- Поддержка тестирования на проде и прочих экспериментов
- Принятие дефектов от клиентов, доведение фидбека клиентов до продакт-менеджеров, и ранжирование полученных дефектов по приоритетам
- Создание дашбордов, отражающих текущее состояние качества продукта
- Иногда они также пишут автоматизированные E2E-тесты и помогают в анализе причин нестабильности тестов.
Они являются ценной ключевой командой, укомплектованной сотрудниками с весьма высоким уровнем скиллов, они обеспечивают культуру качества в WhatsApp, и, по моему мнению, именно они являются клеем, который связывает все воедино и позволяет системе работать. Эта команда (ProdOps/TQS) пользуется сильной поддержкой со стороны руководства.
Лиды в Feature-командах
В дополнение к этому WhatsApp назначила разработчика из каждой Feature-команды на роль специального Test Lead, который отвечает за анализ плана тестирования на текущий квартал, выявляет области, в которых не хватает тестового покрытия, и раздает задачи по написанию тестов для этих областей. Кроме того, они работают с командами, развивая их знания об инструментах и фичах находящихся в разработке, и способствуют повышению соответствующих скиллов в командах.
Регулярно проводятся совещания, на которых эти тест-лиды представляют свои тест-планы, получают фидбек, а затем помогают в реализации функций.
Весь проект контролируется Leadership SWE компании WhatsApp.
На мой взгляд, создание именно такой новаторской структуры управления стало фактором, обеспечившим известную надежность WhatsApp и очень стабильные релизы.
Итак
Подведем итоги:
- WhatsApp широко использует автоматизацию для повышения качества и расширения тестового покрытия
- При этом разработчики в WhatsApp сами пишут тесты, не только юнит-, но и вплоть до самого высокого уровня пирамиды: e2e, и даже занимаются monkey и exploratory тестированием
- Команда автоматизации (SDET) помогает другим в создании инфраструктуры и инструментов
- Команда ProdOps QA поддерживает команды Infra и Feature, контролируя соблюдение хартии качества
- Выделенный менеджмент (thought leadership), склонный к экспериментам в SDET и ProdOps, обеспечивает эти практики
- Поддержка этих команд со стороны высшего менеджмента и ввод в состав команд талантливых сеньоров помогает двигаться в правильном направлении.
Все команды работают над общей целью — быстрее выпускать качественный код. Как видите, автоматизации и обеспечению качества в WhatsApp уделяется очень большое внимание со стороны руководства компании.»
