Пользовательские инструменты для управления тестовым стеком
Развитие QA приложений в Azimo
Это третья из серии сообщений в блоге, в которых мы рассказываем о нашем многолетнем опыте тестирования приложений для Android в Azimo. Большинство принципов, целей и достижений применимы и к нашему приложению для iOS.
Содержание
- Эволюция QA приложений, первые дни и модульное тестирование
- QA-инженеры, функциональное и UI тестирование
- (Этот пост) - Пользовательские инструменты для управления стеком тестирования
- Удаление и вычитание тестов - тоже часть разработки
- QA-тестирование в облаке
Примерно через три года разработки мы значительно улучшили наш стек тестирования и качество приложения. От 0 тестов до примерно 60% покрытия модульными тестами, от ручного тестирования QA до сотен функциональных и пользовательских тестов, запускаемых автоматически, от одного выпуска в два месяца до новой версии приложения, публикуемой в магазине каждые две недели. Стабильность приложения выросла с бесчисленных сбоев до 99% пользователей без сбоев.
Мы достигли всего этого с помощью относительно небольшой команды из 3–4 инженеров-программистов и 1 инженера по обеспечению качества, отдельно для Android и iOS. Изменения вносились постепенно, квартал за кварталом, благодаря сознательному управлению целями.
Мы никогда не останавливали разработку продукта более чем на 1-2 недели.
Хотя результаты нашей работы были впечатляющими, мы также начали сталкиваться с новыми проблемами. С сотнями функциональных тестов и тестов пользовательского интерфейса используемые нами инструменты (Fastlane с нашим настраиваемым плагином, Spoon и другие) больше не подходили для наших нужд. Вот некоторые из проблем, с которыми мы столкнулись:
- Наш тестовый костюм, мягко говоря, зарос. Из-за этого невозможно было запустить все тесты сразу. Одного пробега хватило бы более чем на 5 часов. А из-за большой нестабильности сдать все тесты было практически невозможно. Решения для сегментирования тестов, предоставляемые Android не очень подходили для наших нужд (например, из-за неправильной балансировки количества тестов).
- Наш тестовый стек было трудно отлаживать - результаты набора тестов, логику запуска тестов, связь ADB или управление AVD. Мы даже определили некоторые конкретные требования для их улучшения. Но из-за недостатка компетенций (например, отсутствие инженеров по языку Ruby) во многих случаях мы могли рассчитывать на помощь сообщества и ответы на проблемы, о которых мы сообщали.
Руководитель испытаний автоматизации
Имея это в виду, мы решили создать наш внутренний инструмент для управления циклом тестирования. AutomationTestSupervisor, который мы разработали с нуля на Python, дал нам полный контроль над:
- Ведение журнала на многих этапах выполнения теста - от создания и развертывания приложения до запуска тестов и анализа результатов до взаимодействия с ADB.
- Разделение тестов на пакеты, сегментирование, повторный запуск неудачных тестов,
- AVD и управление устройствами, включая настройку эмуляторов с помощью простого файла конфигурации.
Мы написали отдельные сообщения в блоге об AutomationTestSupervisor, в которых мы более подробно освещаем наши проблемы и мотивацию. Вы можете прочитать его здесь: История создания AutomationTestSupervisor - нашего специального инструмента для тестирования автоматизации Android.
Вот чего мы достигли благодаря созданию собственного инструмента:
- Мы могли проводить параллельное тестирование с множеством устройств и эмуляторов на одном компьютере. На Macbook Pro с 32 ГБ / ОЗУ мы могли запускать 5–6 эмуляторов одновременно.
- Мы сократили время тестирования примерно на 50% (с ›5 часов до 2–3 часов для полного тестового костюма).
- Отладить наши тестовые прогоны было намного проще благодаря журналам и настраиваемым панелям мониторинга с информацией о нестабильности, времени тестирования и осколках (см. Снимок экрана ниже).
- Мы избавились от языка Ruby как от зависимости для нашего технического стека. В любом случае Python был частью нашего технического стека как язык сценариев для других решений автоматизации.
- Избавление от Ruby и переход на AutomationTestSupervisor также входили в нашу цель - полностью отказаться от Fastlane (который был заменен конвейерами Jenkins).
- Из-за сокращения времени тестирования мы можем перейти на недельную серию релизов. Быстрое тестирование, небольшие фрагменты изменений, внедряемые в производственную среду, более быстрое экспериментирование и циклы обратной связи - все это также изменило правила игры в разработке продукта.
Создать собственный инструмент с нуля непросто, особенно если ваша команда инженеров небольшая. Вы берете на себя полную ответственность за поддержку и развитие. И вы получаете очень небольшую поддержку со стороны внешнего мира. Это был один из уроков, которые мы извлекли с течением времени, но тогда выгода, которую мы получили, была намного больше.
Недельный выпуск релизов изменил правила игры для нас с точки зрения разработки продукта. В следующем сообщении блога мы расскажем вам об этом больше. Быть в курсе!
