Всем привет! Я Лид тестирования в одной из компаний и поделюсь своей историей решения проблемы, когда регрессионное тестирование становится бутылочным горлышком всего процесса.

Предыстория. В этом году направление получило взрывной рост и количество команд утроилось (стало 15 команд), а количество QA- специалистов стало превышать 20+ человек. Довольно быстро выявились следующие проблемы:

1. Увеличение сложности управления. Большие команды сложно контролировать. Без прозрачности работы растут лишние затраты времени, коммуникации или 1:1 стали отнимать запредельное количество времени.

2. Нестабильность результатов. Чем больше людей, тем сложнее синхронизировать действия, начали просачиваться баги в релиз, общее количество багов вырастало от квартала к кварталу.

3. Увеличился регресс. Регрессионное тестирование становится узким местом: множество тест-кейсов выполняется медленно, а что еще хуже его тормозят сами владельцы команд, пропихивая вперед регресса бизнес-фичи – отнимая время QA.

4. Полноценный регресс. Полное регрессионное тестирование стало занимать время больше, чем было отведено времени на спринт(2 недели).  В таком случае для QA это все превращалось в один бесконечный регресс.

Давай примем, что регресс у нас занимает 14 дней, а в конце решения буду приводить сколько оно позволило сэкономить дней.

Первые приседания

Для получения того, чтобы процесс релизов не встал, а люди не выгорали от бесконечных регрессов была внедрена практика “Анализ влияний изменений на проект”. Суть его заключается в том, что зная архитектуру приложения и внутренние зависимости, можно определить какие модули были затронуты, а следовательно определить объем требуемого регресса.

Как это выглядит на практике. Команда А сделала, доработку Кнопки Продолжить. Значит в регрессе будут участвовать тест-кейсы, где есть экраны с данной кнопкой, а остальной функционал достаточно закрыть смоук-тестами. Особенно этот анализ выручает, когда элементы задевают несколько команд, и объем регресса можно перекрыть тестами нескольких команд.

Такой подход помог особенно нагруженным командам, чей объем тест-кейсов превышает более 1к тестов.

Регресс стал занимать около 10 дней. Пункт 4 вычеркиваю.

Удивительные приседания

Общее количество тест-кейсов в регрессе уменьшилось, а понимание почему отдельные команды регресс выполняют удивительно медленно, остался. Лезем под капот и удивляемся.

Как задумывалось

QA инженер получает от Лида тестирования задачу о том, что можно приступать к регрессу, т.к. артефакт тестирования доступен. QA знакомится с Эпиком на регресс, в котором присутствует описание что и в каком объеме требуется протестировать, какие модули затронуты или новые фичи добавлены. На этом основании формируется набор тест-кейсов на регресс и QA-приступает к задаче.

Как оказалось

1. QA‑сформировал набор тест‑кейсов и ушел выполнять бизнес‑задачи, т.к их приоритизировал владелец команды.

2. QA — сформировал набор тест‑кейсов и ушел заниматься делами не связанными с работой.

Сразу появляется простое решение в голове идти ругаться с РО и QA, но оно конечно не приведет ни к каким результатам. Наше решение — это получение метрик, на основании которых уже можно принимать решения, в том числе и управленческие.

Для того, чтобы оценить в среднем сколько времени у отдельного QA уходит на регресс, мы определяем среднее время прохождения тест-кейса, для того чтобы получить первые значения, от которых можно оттолкнуться. По каждой из тематик проходим тест кейс руками, и прибавляем условные х2 времени, в дальнейшем мы сможем это отрегулировать куда точнее.

Пример расчёта

• Среднее время прохождения тест-кейса: 4 минуты.

• Регресс: 40 тест-кейсов.

• Общее время: 40×4=160 минут=2,67 часа

В это же время история регрессов показывает, что сотрудник выполнял регресс около 4 дней или 32 часа, а также регулярно жаловался на загрузку и объем работы. Уже как минимум повод для проведения беседы появился.

Ситуация, когда РО приоритизировал задачу и оторвал QA от регресса решил следующим образом. Вводится термин “Украденное время”, и во время регресса в Jira можно отфильтровать задачи, которые поменяли статус “В Тестирование” на статус “К релизу”. У каждого “Украденного часа” есть своя стоимость, рассчитанная совместно с экспертами. Условно приложение могло выйти 20 числа и заработать за день Х количество денег, но вышло 22 числа и недозаработало – сумму за 2 дня. Готов поспорить, что полученная сумма может оказать больше годовой зарплаты хитрого РО. Обычно, при демонстрации таких данных, вопрос отвлечения QA инженеров сразу отпадает.

Регресс стал занимать около 6 дней. Пункт 3 вычеркиваю.

Заключение

Проблемы 1 и 2 я разберу в следующей статье.
Рассказываю интересные истории в своем Telegram-канале.