Software Developer In Test: как мы отказываемся от регрессионного тестирования

Сегодня подробно расскажем о том, как мы трансформируем процессы тестирования: внедряем стандарты автоматизации и встраиваем автоматические тест-планы в процесс разработки.

В начале прошлого года мы в True Engineering сформулировали корпоративную стратегию «Общего инжиниринга», в рамках которой мы разрабатываем свою базу подходов и стандартов и унифицируем рабочий процесс. Мы разработали единые требования к ведению проектов, а также к архитектуре, развертыванию и поддержке наших продуктов.

Для оптимизации процесса тестирования, основной целью которой было сокращение time-to-market (TTM) продуктов, мы взяли на вооружение концепцию SDET (software developer in test). Она предполагает, что QA-инженер сопровождает продукт на протяжении всего жизненного цикла, а не подключается к тестированию в самом конце. Такой подход гарантирует нам не только снижение времени на тестирование, но и непрерывный контроль качества.

Как мы внедряем SDET в работу наших команд

SDET в нашем понимании – это определенный набор функций от составления общей стратегии тестирования до написания автоматических тестов и ручного тестирования, если это потребуется. Эти функции можно отдать отдельному специалисту, но мы выбрали другой вариант – распределить их внутри наших команд.

Общие требования к процессу тестирования для всех команд

  • Регрессионный чек-лист в Azure DevOps - встроен в CI/CD;
  • Набор автотестов, покрывающих регрессионный чек-лист;
  • Отчеты в разрезе регрессионного чек-листа по результатам прогона;
  • Составление чек-листа до начала разработки фичи;
  • Разработка автотестов по чек-листу;
  • Метрики покрытия тест-планов автотестами.

Кастомизация пайплайнов Azure DevOps

Пайплайны Azure DevOps позволяют запускать автоматические тесты и получать по ним отчет. При этом было непонятно, как сопоставить этот отчет с чек-листом и сформировать его в нужном для нас виде. Поэтому мы разработали кастомное расширение для Azure DevOps, которое ассоциирует автотесты и тест-кейсы.

Software Developer In Test: как мы отказываемся от регрессионного тестирования

Как наши команды внедряют принципы SDET в свою работу

· Силами разработчиков настраивают тестовое окружение и пайплайны Azure DevOps;

· Определяют типы автотестов для покрытия кода (unit-тесты, интеграционные, сценарные);

· Учатся писать соответствующие типы тестов по нашим стандартам;

· Составляют план по написанию автоматических smoke-тестов для проверки ключевых функций;

· Настраивают отчеты по автотестам на основе тест-планов;

· Прорабатывают дорожную карту и план по внедрению SDET в проекте, согласовывают с заказчиком и включают соответствующие задачи в спринты;

· Выбирают и настраивают инструмент для измерения покрытия кода (Sonar Qube, JaCoCo или Cobertura). Актуально только для Unit-тестов - задача состоит в том, чтобы контролировать и поддерживать необходимую степень покрытия кода.

Покрытие кода автотестами – процесс, который может длиться бесконечно, и подходить к нему нужно адекватно. Мы всегда тщательно рассчитываем объем нужного покрытия/ критичность покрываемых функций/затраты на него. Во-первых, не все фичи в принципе хорошо тестируются автотестами. Например, фичи с монотонной, понятно описываемой логикой долго и муторно тестировать вручную, но для автоматизированного тестирования это идеальный вариант. В то же время небольшие доработки вроде изменения цвета на одной кнопке проще будет проверить руками.

Во-вторых, наш опыт показывает, что уровень автоматизации должен быть достаточно высок, но приблизиться к 100% он может только на продуктах, которые не развиваются. В условиях, когда рынок и бизнес почти мгновенно реагируют на новшества, продукты должны быть гибкими и проактивными. TTM и возможность изменять продукт под новые идеи и вызовы играют здесь ключевую роль.

11
3 комментария

Комментарий недоступен

Ответить

лол, автоматизаторов дрючат на собесах ничуть не меньше чем разработчиков мидлов частенько

Ответить

как QA инженер скажу так:
1) майндсет тестировщика и разработчика разные
2) в автоматизации надо знать дофига разного, в зависимости от того, с чем работаешь. например знать java/python , junit/selenium, sql, git, MQ, http протоколы, api (rest/soap), xml, json, jenkins/teamcity, azure, docker, linux
3) техники тест-дизайна придуманы не просто так. разработчику в голову не придут различные варианты проверок, он по умолчанию думает что все работает как надо.
4) если баги не найдены - не значит что их нет.

Ответить