- А что такое Реддит
- Как они тестируют Android
- Тестирование iOS-приложения
- Стратегия
- Инструментарий
- Функциональные тесты
- Интернационализация и локализация
- Push-уведомления
- Фича-флаги
- Выполнение тестов
- Nightly-билды и RC
- Pull Request Gateway
- Как повысили стабильность тестов
- Что делаем с нестабильными
- Репорты
- Приоритизация
- Slack-уведомления
- CI-чеки
- Интеграция с TestRail
- Обучение команд
- Вопросы и ответы по iOS
Что собой представляет Reddit
Reddit — популярная в англоязычном мире платформа для общения. Отчасти напоминает блог-платформу вроде ЖЖ; минималистичным дизайном напоминает классический форум; обилием картинок походит на имиджборд типа Пикабу или Двача. По охвату и влиянию это «народная» социальная сеть типа Вконтакте/Одноклассников, но с поправкой на особенности аудитории — половина американцы, также канадцы и европейцы, большей частью образованные мужчины до 40 лет из среднего класса. Пользователь сам формирует себе ленту, подписываясь на интересующие тематики.
Почему была забастовка
Две трети пользователей посещают сайт через мобильные приложения. В статье на Хабре утверждается, что официальное приложение это «гроб на колесиках, неудобный и глючный монстр, предмет постоянной критики пользователей». Однако красноречивая статистика скачивания, по крайней мере Android-приложений (в iOS ситуация примерно такая же):
— говорит либо о том, что официальное приложение Reddit не такой уж гроб на колесиках, либо просто пользователи не знают о существовании неофициальных приложений, что маловероятно, принимая во внимание технологическую подкованность среднего пользователя Reddit.
С начала существования платформы ее владельцы были не против неофициальных мобильных приложений, и доступ к API всегда был бесплатным. Неофициальных приложений ну очень много; но, в основном (судя по названиям в списке выше) они ориентированы на существенное улучшение лишь какой-то одной или нескольких функций; и часть этих приложений очень даже платные.
Владельцем Reddit является крупнейшая американская медиакомпания Advance Publications, которой принадлежит самый известный познавательный телеканал Discovery, авторитетный ИТ-журнал Wired, дамские и мужские лайфстайл-журналы, большая доля в кинокомпании Warner и прочая и прочая. Многолетняя терпимость владельцев портала к неофициальным приложениям (и нагрузке создаваемой ими), объяснялась видимо тем, что нагрузка была небольшой, и, наверное, тем что исторически эта медиакомпания ориентирована на средний класс с его повышенными запросами — но и повышенной платежеспособностью (а не на максимально широкую и непритязательную аудиторию), и ранее владельцы как-то находили способы монетизации без взимания платы за доступ.
В начале лета обитателей платформы всколыхнул грандиозный скандал. Владельцы, видимо устав глядеть на полуторамиллиардную посещаемость (в месяц) самой платежеспособной аудитории в мире — и ничего с этого не иметь, решили что-то пробовать с монетизацией. Но были предприняты, по мнению большинства пользователей, неприемлемые и попросту репрессивные вещи. Владельцы закрыли внешним компаниям бесплатный доступ к API, и установили цены на платный доступ на уровне, делающем бессмысленной бизнес-модель большинства существующих сторонних мобильных приложений (то есть $0,24 за тысячу запросов к API оказалось чрезмерно).
Утверждалось также, что доступ к API ограничивается и из-за того, что крупнейшие мировые технологические корпорации принялись обучать свои языковые ИИ-модели на огромном массиве данных живого общения между людьми. И уютный Реддит, как ценнейший источник (судя по отрывочным данным, самый ценный из имеющихся в распоряжении), пал первой жертвой ненасытных корпораций. Выходило так, что Реддит достаточно долго выступал бесплатным донором, не получая за это ни цента.
Итак, вспыхнул конфликт между владельцами (администрацией) платформы, и ее пользователями. Те, успев привыкнуть к сторонним приложениям, в ответ устроили нечто вроде забастовки, пытались повлиять на администрацию словесно, а также закрытием тредов для новых подписчиков, а модераторы (работающие бесплатно и добровольно) проявили солидарность с обитателями платформы, и даже выступили лидерами протеста. Конец был предсказуем — администрация победила, как и в 99,999% подобных случаев. Но это присказка.
Итак. Что собой представляют «гробы на колесиках», то есть официальные мобильные приложения Reddit, и как их тестируют — в рассказе команды Reddit об инструментах, подходах, и процессах тестирования, в двух частях.
Часть 1: Android.
«Кратко:
- Автоматизация UI-тестов является важнейшим аспектом в тестировании наших мобильных приложений. Исходя из этого мы тщательно подбираем инструменты под задачи, фреймворки, и применяем следующие подходы: изоляция тестов, группирование тестов (sharding), test rules, и детальные отчеты.
- Применяются лучшие практики для Android, в частности сдвиг влево и паттерны проектирования Page Object Model и Fluent Design, что позволяет преодолеть сложности с автоматизацией и добиться высокого покрытия.
- В целом автоматизация таких сложных и высоконагруженных приложений требует очень тщательного планирования, реализации и сопровождения.
Инструменты
Фреймворки — основа процесса автоматизации UI-тестов. Они обеспечивают структурную базу для создания тестов, управления ими и выполнения. В Reddit в целом стараются придерживаться стратегии сдвига влево. Чтобы более активно задействовать QA-автоматизаторов и разработчиков на ранних этапах цикла, в Reddit видоизменили существовавшие инструменты, сделав их более ориентированными на разработчиков.
Несмотря на то что для автоматизации в Android существуют например UIAutomator, Espresso и Jet Pack Compose, они не обеспечивают чистоту кода «из коробки». Это снижает продуктивность и дублирует код, если дизайн не идеален. Для решения этой проблемы мы используем паттерны проектирования, в частности паттерн Fluent и Page Object Pattern.
Борьба с избыточным кодом традиционными методами
С помощью традиционного Page Object Model мы пытались создать некие стандартные функции, выполняющие действия на экране. С применением UIAutomator без описания методов получался примерно такой код:
Инкапсуляцией действий в методах с помощью эксплицитного ожидания можно повторно использовать код во многих тестах, что значительно ускоряет написание Page Objects.
Паттерны ускорили создание тестов
Мы применяем следующие паттерны проектирования в автоматизации интерфейса: POM [прим. — подробный гайд здесь] и паттерн Fluent. Что позволило нам улучшить:
- Реюзабельность
- Читаемость
- Масштабируемость
- Обслуживаемость
- И коллаборацию в командах
Подробно о применении POM
Итак самый применяемый у нас паттерн — POM, позволяющий улучшить сопровождаемость (maintainability) тестов за счет снижения дублирования их кода. Поскольку каждая страница представлена отдельным классом, любые изменения на странице могут быть реализованы в одном, а не нескольких классах.
Ниже видим типичный автотест, написанный без применения POM. С ним проблема: когда изменяем ID элемента, нужно также изменить все ID во всех функциях в которых использован этот элемент.
Показанный здесь метод можно улучшить, создавая объект страницы, который абстрагирует большинство повторяющихся действий (как ниже на рисунке); обычно при изменении элементов можно просто обновить их в одном месте.
Ниже видим типичный тест, использующий POM. Выглядит намного лучше: каждое действие может быть выполнено «одной строкой», и большая часть кода — реюзабельная.
Если нам понадобилось например повторно задействовать эту же функцию, скажем для теста проверки сообщения о недопустимом имени/пароле; то это выглядит примерно так: просто меняем verify-метод, а все остальное в тесте остается неизменным.
Такой паттерн не решает всех проблем, тест все еще не функционален, а больше похож на набор общих инструкций. Также, будет дублированный код — но его можно абстрагировать.
Паттерн Fluent Design
Предполагает выстраивание цепочек (чейнинг) вызовов методов в стиле естественного языка, так чтобы код автотеста выглядел как последовательность шагов. Такой подход облегчает понимание предназначения теста, и делает код как бы само-документированным. Паттерн может использоваться с любой базовой тестовой библиотекой, в нашем случае UIAutomator или Espresso.
На практике создается к примеру BaseTestScreen, подобный показанному ниже. Выгода от метода verify в том, что каждый класс, наследующий этот метод, может автоматически верифицировать экран, к которому он относится; а также возвращать сам объект, который дает все общие методы, определенные в объектах экрана.
Класс экрана можно усовершенствовать при помощи общей функции (которая была показана в начале), что уменьшает количество кода и делает его более читабельным:
Тест уменьшился, стал более читабельным, и отображает интент бизнес-логики:
Инъекции зависимостей
Наши тесты взаимодействуют с пользовательским интерфейсом приложения и проверяют правильность его отображения, но нам нужны также тест-кейсы, проверяющие поведение приложения. А именно тестирование событий. Если приложение регистрирует определенные события, то в нем должны быть тесты, проверяющие, как оно это делает. Если эти события не касаются пользовательского интерфейса, то приложение должно предоставлять API для тестов вызова событий. Однако, не во всяком приложении могут быть такие API.
В Android-приложении Reddit используется Anvil и Dagger для инъекции зависимостей, чтобы запускать тесты приложения, в котором модуль событий заменён тестовой версией. Модуль событий зависит от этого интерфейса.
Мы можем написать класс TestEventOutput, имплементирующий EventOutput. В TestEventOutput реализован метод send(Event) сохранения любого нового события в изменяемом списке Events. Также добавили методы определения, есть ли событие в этом списке. Сокращенная версия класса:
Как видим, метод send(Event) добавляет каждое новое событие в список inMemoryEventStore.
Класс также предоставляет метод public getOnlyEvent(String, String, String, String, String?), который возвращает единственное событие в списке, свойства которого соответствуют параметрам этой функции. Если таковых нет или их больше одного, то функция выдает assertion. Также там есть функции, которые не выдают assertion при совпадении нескольких событий и возвращают первое или последнее событие в списке, но для краткости они опущены.
Последнее: создать замещающий модуль событий, который предоставляет объект TestEventOutput вместо прод-имплементации интерфейса TestEventOutput.
После этого можно имплементировать методы верификации событий, подобные этому:
Затем можно вызывать эти методы проверки событий. »
Вопросы и ответы по Android
В коментах (которые на Реддите часто бывают интереснее чем сам материал) спрашивают:
Вопрос: «Почему не используете blackbox-фреймворки типа Appium и Maestro?»
Ответ: «Они хороши, но наш фреймворк ориентирован на разработчиков; им легко работать с ним; также у нас кастомные интеграции для которых лучше подходит именно UIAutomator; например используем Macrobenchmark для тестирования производительности, и тест из UIAutomator можно сразу использовать в Macrobenchmark.»
Вопрос: «А в iOS те же подходы и стратегия?»
Ответ: «В принципе да, дизайн-паттерны практически те же. Но здесь больше кастомных интеграций специфичных для Android. Типа paparazzi для скриншотов.»
Часть 2: iOS
« iOS-версия официального мобильного приложения Reddit релизится каждую неделю. Сколько пользователей? Много: 15 миллионов. Сколько тестов? У нас 17 000 одних только юнит-тестов и скриншот-тестов, покрывающих бизнес-логику и дизайн.
А сейчас обсудим сквозные UI-тесты, которые играют важнейшую роль в обеспечении доступности Reddit каждую секунду.
Кстати о доступности. Активных пользователей (в смысле зарегистрированных и активно общающихся) 36 миллионов, причем как правило это образованные и требовательные пользователи (и состоятельные — т.н. Tier 1). 1,6 миллиарда просмотров страниц в месяц (в одной весовой категории с Twitter, Instagram, LinkedIn и TikTok).
Стратегия тестирования
До 2021 года все user flow в iOS-приложении Reddit тестировались вручную внешним подрядчиком. QA-процесс обычно занимал 3-4 дня, иногда больше при необходимости исправления критических ошибок и повторного тестирования. Руководство понимало, что ждать примерно 60% рабочего времени недели, пока релиз протестируют — нецелесообразно и немасштабируемо, особенно когда нужно срочно выпустить хотфиксы.
Поэтому была создана выделенная команда Quality Engineering (QE), в рамках простой концепции: сдвиг влево + разделение ответственности за качество продукта с feature-командами. Задачи были сформулированы следующие: создать удобные для разработчиков инструменты тестирования, фреймворки, дашборды и процессы, с помощью которых QE-команды могут писать, запускать, отслеживать и поддерживать тесты. Это должно было позволить QE-командам получать быстрый фидбек по изменениям в коде, просто запуская соответствующие автоматизированные тесты локально или в CI.
В данное время:
- Разработано около 1800 сквозных тестов UI, с приоритетом от P0 (блокер) до P3 (незначительный).
- Время тестирования релиз-кандидата (RC) сократилось с 3-4 дней до менее чем 1 дня
- Мы запускаем небольшой набор смок-тестов с приоритетом P0, аналитических тестов событий, и тест-свитов производительности — на нашем шлюзе Pull Request Gateway, с целью выявить критические ошибки до слияния.
- Каждый вечер на основной рабочей ветке и на сборках релиз-кандидатов мы запускаем полный набор тестов: дымовых, регрессионных, событий и push-уведомлений. Их выполнение занимает 1-2 часа, а ревью — до 3 часов в зависимости от количества упавших.
- Смок- и регрессионные свиты релизов раз в неделю — тестирование локализации и интернационализации
Такое мощное покрытие позволяет уверенно выпускать релизы каждую неделю.
Инструменты
Важнейшая составляющая правильного QA-процесса. В Reddit реализована поддержка множества подтипов тестов с помощью наших собственных тестовых фреймворков:
- UITestKit — для функциональных тестов и тестов push-уведомлений.
- UIEventsTestKit — тесты событий аналитики/телеметрии.
- UITestHTTP — HTTP прокси-сервер для заглушек сетевых вызовов.
- UITestRPC — RPC-сервер для получения или изменения состояний приложения.
- UITestStateRestoration — чтение и запись файлов из/в хранилище.
Итак, эти фреймворки позволяют нашим QA-инженерам писать следующие подтипы UI-тестов:
- Функциональные
- Аналитики событий
- Push-уведомлений
- Экспериментальные
- Интернационализации и локализации
- Производительности (но их выполняет внешний контрактор)
Цель состоит в том, чтобы тестировщики могли быстро писать идеальные сквозные UI-тесты как часть Pull Request, имплементирующего новую функцию или модифицирующего существующую. Далее представим обзор того как происходит написание UI-тестов iOS-приложения Reddit.
Написание тестов
Наши UI-тесты пишутся на языке Swift и используют XCUITest (то есть XCTest) — язык и фреймворк тестирования, хорошо знакомые всем iOS-разработчикам. Как и в фреймворке сквозного тестирования для Android (о котором мы рассказали в 1 части обзора выше), UI-тесты для iOS следуют паттерну Fluent Interface (здесь о нем подробно), который делает их более выразительными и читабельными за счет создания цепочек (чейнинга) методов действий (методов, имитирующих действия пользователя) и assertions.
Перейдем к примерам.
Функциональные тесты
Самые обычные сквозные тесты, которые проверяют, что действия пользователя соответствуют ожидаемому поведению приложения.
Аналитика событий
Как бы продолжение функциональных, но вместо проверки функциональности они проверяют аналитические события, связанные с действиями пользователя и передаваемые приложением.
Интернационализация и локализация
Мы запускаем существующий свит функциональных тестов с переопределением языка и локали приложения, чтобы убедиться, что они работают одинаково во всех официально поддерживаемых географических регионах. Для этого используем два подхода в наших page-objects экранов:
- Добавлять и по возможности чаще использовать идентификаторы доступности элементов.
- Используем наш кастомный фреймворк локализации для подтягивания переведенных строк в зависимости от выбранного языка приложения.
Ниже пример, как фреймворк локализации определяет положение элемента вкладки «Posts» по его независимой от языка метке:
Assets.reddit.strings.search.results.tab.posts возвращает строковую метку на языке, установленном для данного приложения. Также можем оверрайдить язык приложения и локаль для некоторых тест-кейсов.
Push-уведомления
Наша система тестирования push-уведомлений использует SBTUITestTunnelHost для вызова push-команды xcrun simctl с предопределенным содержимым уведомления, которое деплоится на симуляторе. После успешной отправки мы верифицируем, что уведомление отображается в симуляторе, и его содержимое сверяется с ожиданиями, полученными от уведомления. После этого происходит взаимодействие с уведомлением, чтобы активировать связанный с ним диплинк, который проходит через различные части приложения — что позволяет проверить целостность всех остальных действий (navigation flow).
Эксперименты (Feature-флаги)
В связи с тем, что UI-тесты требуют значительных затрат на их поддержку, тестирование краткосрочных экспериментов с помощью UI-тестов, как правило, не рекомендуется. Однако мы одобряем добавление покрытия UI-тестами всех экспериментальных функций, которые могут постепенно переводиться в статус feature rollout (то есть стать официальными). В таких тестах приложению при его запуске могут передаваться имя эксперимента и его версия.
Выполнение тестов
Тестировщики могут запускать UI-тесты локально с помощью Xcode, в терминале с помощью Bazel, в CI на симуляторах, или на реальных девайсах с помощью BrowserStack App Automate. Запланированные ночные и еженедельные тесты, упомянутые в начале, в разделе «Стратегия», запускают QA-билд приложения на реальных устройствах с помощью BrowserStack App Automate. Однако шлюз Pull Request Gateway запускает отладочную Debug-сборку в CI на симуляторах. Мы используем симуляторы для всех тестов не по «черному ящику», поскольку они обеспечивают бОльшую гибкость по сравнению с реальными устройствами (например, с помощью simctl или AppleSimulatorUtils).
В настоящее время мы тестируем на iPhone 14 Pro Max и iOS 16.x, кажется это самая быстрая комбинация устройств и версий iOS для UI-тестов.
Nightly-билды и релиз-кандидаты
Выполнение полного тест-свита из 1700 тестов занимает до 2 часов на платформе BrowserStack для ночных и релизных сборок, и в этом году будем сокращать до одного часа.
Колебания времени выполнения вызваны разной доступностью параллельных потоков (устройств) в нашем BrowserStack-аккаунте, и количеством повторных попыток выполнения при неудачных запусках. Мы запускаем все три свита одновременно, поэтому сложные регрессионные тесты не успевают получить все шарды до завершения быстрых дымовых тестов и тестов событий. Планируем решить эту проблему в ближайшие месяцы и сократить время выполнения полного тест-свита до одного часа.
Pull Request Gateway
Мы запускаем подмножество дымовых и событийных тестов с приоритетом P0 на per-commit push для всех открытых Pull Requests. Они запускаются в параллельных рабочих процессах CI и параллельно распределяют тесты между двумя симуляторами. Ниже показано время билда, включая сборку дебаг-билда приложения Reddit, для этих тестов в марте:
- Дымовые (19 тестов): p50 — 16 минут, p90 — 21 минут
- Тесты событий (20 тестов): p50 — 16 минут, p90 — 22 минут
В среднем на выполнение тестов в обоих случаях уходит ~13 минут. Планируем увеличить количество параллельных симуляторов, чтобы значительно сократить это время.
Как обеспечиваем стабильность тестов
Компания вложила значительные средства в обеспечение стабильности тестов. В марте поддерживали средний показатель pass rate ночных тестов (дымовых, событий и регрессионных) на уровне ~90%. Цель на следующий квартал — достичь и поддерживать средний уровень прохождения тестов 92%.
Ниже приведены несколько наиболее важных функций, которые мы внедрили с помощью UITestKit и сопутствующих библиотек, чтобы повысить стабильность тестов:
- Программная аутентификация вместо UI для входа в систему в тестах, не имеющих отношения к аутентификации
- Использование диплинков (Universal Links) для быстрого перехода к началу тестовых действий (например к конкретному посту в Reddit), и отсечения ненужных или не связанных с тестом шагов, которые могут быть нестабильными.
- Сброс состояния приложения между тестами, чтобы «очистить» тестовое окружение для определенных тестов.
- Использование аргументов запуска приложений для конфигурации приложений, которые могут прерывать или замедлять тестирование:
- Ускорение анимации
- Отключение уведомлений
- Пропускать промежуточные экраны (например при входе в систему)
- Отключение всплывающих подсказок
- Отказ от всех активных feature flags
Если тесты падают, повторно запускаем их вне тестового фреймворка, до 3 раз.
Что делаем с нестабильными тестами
Мы разработали сервис для обнаружения и помещения в карантин нестабильных тестов, что позволяет снизить вероятность непредвиденных сбоев в работе CI и сократить расходы на инфраструктуру. Сервис работает по недельному расписанию, анализируя журналы падений после мержей и ночных прогонов. Обнаружив тест-кейсы, частота падения которых превышает определенный порог, служба помещает их в карантин, исключая возможность их запуска в последующих прогонах. Кроме того, сервис генерирует тикеты на исправление тестов, помещенных в карантин, тем самым заставляя владельцев тестов исправлять их, повышая стабильность. Сейчас сервис охватывает только модульные и snapshot-тесты, но мы планируем расширить сферу его применения и на UI-тесты.
Репорты
Мы создали три пайплайна репортов для фидбека по результатам тестирования UI для команд с разным уровнем технических и нетехнических скиллов:
- Уведомления в Slack с кратким обзором — для команд
- Проверка статуса в CI (блокеры и опционально другие) для создателей Pull Request на GitHub
- Комментарии к Pull Request
- HTML-репорты и видеоролики упавших тестов в качестве артефактов сборки CI
- TestRail-репорты для нетехнических специалистов
Приоритизация тестов
Когда тест падает, важно правильно определить причину чтобы устранить ее. Изучаем тестовый код, тестовые данные, и ожидаемые результаты. После выявления причины, если это баг, создаем тикет для dev-команды, содержащий всю необходимую информацию для ревью и исправления, с учетом приоритета функции. После исправления теста проверяем его, запуская тест с определенным приоритетом.
Такая архитектура фреймворка позволяет выявлять ошибки на ранних стадиях цикла. Выше у пользователя с именем Mod отсутствуют вкладки «Mod Feed» и «Mod Queue», что не позволит ему воспользоваться функциями этого сабреддита из iOS-приложения.
Взаимодействие разработчика и тестировщика в приведенном примере происходит качественно, поскольку тикет ошибки содержит всю нужную информацию: сообщение об ошибке, запись экрана, шаги по воспроизведению, сравнение с прод-версией приложения, ожидаемое поведение и фактическое, лог-файл, и приоритет бага.
Здесь важно отметить, что не все падения тестов связаны с ошибками в коде. Иногда тесты могут падать из-за внешних факторов, например нестабильный интернет или отказ оборудования. В таких случаях проводим повторное тестирование после устранения этих внешних факторов.
Slack-уведомления
Они передаются из тестов, выполняемых в BrowserStack App Automate. Чтобы не блокировать CI на время выполнения тестов и получения результатов, мы предоставляем callback-URL, который BrowserStack вызывает с нужными данными по завершении выполнения теста. Он также позволяет отмечать пользователей тегами, для уведомления владельцев тестов о том, что результаты тестирования релиз-кандидата уже доступны для просмотра.
Чеки в CI
Тесты, выполняемые на шлюзе Pull Request Gateway, сообщают о своем статусе в GitHub, для блокировки Pull Requests с «ломающими» изменениями. HTML-репорты и видеозаписи упавших тестов выступают в качестве артефактов сборки в CI, для отладки. Недавно была введена новая проверка в CI, позволяющая автоматически прогонять тесты экспериментов (с фича-флагами) и сравнивать процент прохождения с базовым уровнем при отключенном фича-флаге. Результаты этой проверки публикуются в виде комментария к Pull Request, а также отображаются в статусе проверки на GitHub.
Интеграция с TestRail
Тест-кейсы всех функций, доступных конечным пользователям, хранятся в TestRail. Как только тест автоматизирован, мы связываем его с ID проекта и ID тест-кейса в TestRail (см. пример кода функционального тестирования представленный выше в этой статье). При запуске nightly-тестов в проекте создается Test Run, в котором фиксируются результаты всех включенных в этот прогон тест-кейсов. Это позволяет нетехническим членам dev-команд наблюдать состояние своих функций в удобном месте.
Обучение команд
Наша стратегия и инструментарий могли быть бесполезными, если бы не было проведено качественное обучение членов команд. В идеале мы хотим, чтобы feature-команды могли писать, поддерживать и владеть этими UI-тестами, поэтому ключевой частью нашей стратегии является регулярное проведение тренинг-сессий по тестированию и качеству в целом.
Когда инструментарий и описанные выше процессы тестирования только внедрялись, мы еженедельно проводили тренинги, во время которых рассказывали о написании и сопровождении тест-кейсов. Теперь мы проводим такие занятия ежемесячно со всеми новыми сотрудниками (на всех платформах) в рамках чек-листа онбординга. Также мы рассказываем о новых функциях и улучшениях на митингах гильдии, и активно взаимодействуем, если кому-то нужна помощь.
Итогом
Инвестиции в автоматизированное тестирование UI в конечном итоге окупятся, если всё сделано правильно. Важно вовлекать в процесс тестирования функциональные команды (продуктовые и проектные), причем делать это на ранних этапах. Создавайте быстрые и надежные петли фидбека по тестам, чтобы ничего не оставалось без внимания.
Вопросы и ответы по iOS
Вопрос: Так кто все-таки пишет ваши тесты, разработчики или тестировщики?
Ответ: У нас «смешанная система», конечная цель которой состоит в том, чтобы QA-команды владели своими UI-тестами, как dev-команды владеют юнит-тестами. Чтобы стронуть с места этот процесс, QA-команда сейчас автоматизирует ручные тесты по приоритетам, затем они будут переданы dev-команде, отвечающей за интерфейс продукта. Это медленный процесс, но он продвигается.
К примеру, наш второй по величине тестовый набор (аналитики событий) полностью передан команде Data Quality, которая теперь поддерживает существующие тесты, пишет новые и регулярно анализирует результаты ночного тестирования и релиз-кандидатов. QA-команда (совместно с командой платформы) только поддерживает инструментарий для него и отвечает на любые запросы по отладке. Мы надеемся добиться того же с остальными тестами/командами.
Вопрос: Кто занимается созданием и поддержкой инфраструктуры и инструментария автоматизации тестирования? Это команда платформы, или горизонтальная команда которая занимается только этим?
Ответ: QE-команды владеют инфраструктурой и инструментарием для UI-тестирования, и при необходимости получают поддержку от команды платформы.
Вопрос: Мне очень нравятся маленькие команды и узконаправленные инструменты для различных типов автотестов. Но как удается поддерживать и масштабировать их в условиях непрерывно меняющегося продукта?
Ответ: Все инструменты, которые мы создали внутри компании, достаточно гибкие и расширяемые и не привязаны к конкретным функциям приложения. Кроме того, мы поддерживаем тесные партнерские отношения со смежными командами, которые либо заранее информируют нас о предстоящих изменениях, либо помогают нам отлаживать/рефакторить когда что-то ломается, чтобы мы могли адаптировать наши инструменты к постоянно меняющемуся продукту.
Вопрос: Весьма содержательная статья. UI-тесты в iOS, как известно, выполняются медленно. Интересно, как выглядит цикл разработки на машине для выполнения UI-тестов и как настраивается производительность тестирования.
Ответ: Как правило, мы не рекомендуем выполнять все UI-тесты локально. Только те, которые связаны с поверхностью (поверхностями) продукта, имеющими отношение к задачам этого члена команды. Мы разложили UI-тесты по папкам, названным в соответствии с поверхностями продукта, что позволяет легко определить тесты, которые необходимо запустить.
В тех случаях, когда инженеры не хотят запускать UI-тесты локально, они могут получить фидбек из CI и затем повторно запустить упавшие тесты локально, для воспроизведения/отладки.
Вопрос: Было бы интересно посмотреть на код фреймворка, и кто над ним работал.
Ответ: Наши разработчики из команды платформы. Возможно в будущем откроют.
Вопрос: 1800 UI-тестов это довольно много. Означает ли это, что ваши усилия по автоматизации тестирования сфокусированы в основном на сквозном UI-тестировании, а не равномерно распределены по различным уровням (e2e, интеграционные) и без разделения модульных между UI и бэкендом? Если что-то можно тестировать на более низком уровне, вы принципиально автоматизируете это на e2e-уровне?
Ответ: У нас соотношение e2e-тестов к модульным примерно 1:10. Обычно мы стараемся не допускать перекрытия тестового покрытия, насколько это возможно, между типами тестов. Однако некоторые поверхности продукта, такие как безопасность пользователей (жалобы, блокировка пользователей и т.д.), в идеале не должны падать вообще никогда. Поэтому мы стремимся к очень высокому показателю покрытия сквозного UI-тестирования — независимо от покрытия на других уровнях тестирования. Это позволяет гарантировать, что критически важные функции будут 100% рабочими в каждом релизе.
