Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы.

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.

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

И объективная реальность такова, что уйти от регрессионного тестирования мы тоже особо не можем — ведь оно как раз обеспечивает нас уверенностью, что новые правки не поломали старый функционал. И что, выкатив супер-крутую свистоперделку в прод, мы его не положим, лишив тем самым наших пользователей не только новой фичи, но и сильно необходимых старых.

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

Я сформулировала шесть основных подходов к работе со временем и набором регресса, плюс еще несколько нюансов, которые могут помочь. Рассмотрим их плюсы и минусы. Погнали!

Вариант первый, самый, казалось бы, простой. Увеличиваем интервал между релизами и тем самым снижаем удельный вес регресса относительно остальных наших активностей. Условно: если регресс занимает 5 рабочих дней команды, то при релизе 1 раз в месяц мы тратим на регрессионное тестирование 15 дней за квартал, а при релизе раз в 1,5 месяца — 10 дней за квартал. Экономия 33%.

Минусы подобного подхода:

• Увеличивается объем релиза, что может привести к увеличению количества дефектов, найденных во время регресса, и увеличению же времени на их исправление, что уже тянет за собой риски по сдвигу релиза.

• Представители бизнеса, как правило, не любят увеличивать интервалы между релизами, для них важнее чаще доставлять новую ценность продукта потребителю. Плюс на релизы могут влиять маркетинговые и законодательные активности.

Вариант второй: проверяем только критичную и/или популярную функциональность. Например, если у нас приложение платежей за электроэнергию, то нам обязательно нужно проверять, что у нас работает функционал оплаты, а вот тестированием верстки справочника видов электросчетчиков можно пренебречь. Тут уже экономия ресурсов составит от скромных 5-10% до почти 90%.

Что стоит иметь в виду при использовании такого подхода?

• То, что не тестируете вы — тестируют ваши пользователи. И готовы ли вы испытывать на прочность их лояльность — решать вам. 

• Иногда бывает сложно определить, что именно является суперкритичным, а чем можно пожертвовать — для решения этой проблемы можно запросить консультацию у представителей бизнеса и заказчиков, воспользоваться данными продуктовой аналитики (например, посмотреть на посещаемость разделов), а еще уточнить у разработчиков и архитекторов: где возможные слабые места продукта с технической точки зрения.

• По закону всемирных неудач, что-то сломаться в непроверяемом месте может в самый неподходящий для этого момент.

Вариант третий: ставим во главу выборки импакт-анализ. То есть формируем набор тестов для регресса, исходя из того, какую функциональность дорабатывали в этом релизе. Хорошо работает с микросервисами, хуже — с монолитами (если архитектура монолита позволяет). Экономия — в зависимости от того, из скольких модулей состоит ваш продукт и сколько из них было задето изменениями. 

Какие риски?

• Вы можете не учесть всю глубину влияния доработок и упустить из проверок важный модуль.

• Образуется слепая зона в вашем продукте, относительно которой не будет уверенности, что там все работает. + вспоминаем пункты про тестирование пользователями и всемирные неудачи.

Вариант четвертый: выбираем самые проблемные части нашего продукта (как правило, те, в которых выявляется больше багов, особенно критичных) и регрессим их. Экономим время, не занимаясь проверками стабильного функционала, сосредотачиваемся на тех объектах, которые требуют нашего пристального внимания.

Что насчет сложностей?

• Чтобы определить проблемный кусок, нужны какие-то данные: статистика по багам, учет времени разработки (например, если оно часто затягивается и не укладывается в оценку), переписки, воспоминания и впечатления от разговоров на дейли — в общем, надо как-то отслеживать ситуацию. Для этого желательно использовать какой-то инструмент с возможностью сбора объективных данных, вроде тех же метрик по количеству дефектов, возвратов задач на доработку, времени задачи в статусе “в работе”. Хорошо, если этот инструмент уже есть и настроен, сложно, если это только предстоит сделать. В качестве альтернативы можно рассмотреть экспертный подход, но для него нужно быть достаточно хорошо погруженным продукт и работу над ним, то есть тоже с бухты-барахты не применишь.

• Риски слепой зоны все так же остаются с нами.

Вариант пятый: прохождение только позитивных проверок. То, с чего стоит начинать любой регресс — это убедиться, что функционал работает при нормальных условиях. Если он не дает пользователю пройти хеппи пас, то о каком релизе вообще идет речь? Неплохо экономит время, больше применимо на стабильном функционале с малым возможным количеством ошибок или же, например, на сервисах, входные и выходные данные для которых поставляют и потребляют другие сервисы, а не люди. 

Минусы:

• Пропущенная некорректная обработка ошибок может вызвать большой негатив у пользователей и у держателей смежных систем, которым эти ошибки могут неприятно поломать работу.

Вариант шестой: автоматизация. Думаю, даже в пояснениях не нуждается. Автоматизируем те кейсы, которые можем, и перестаем тратить время на прохождение мануального регресса по ним. Все счастливы.

Но, как всегда, есть нюансы:

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

• На то, чтобы поднять автотестирование на проекте, нужно время. Так что по щелчку решить проблему не получится и до ближайшей экономии времени на регрессе еще как минимум пара месяцев (а на самом деле больше).

• Не все кейсы автоматизируются, так что часть все равно останется на совести мануальных проверок.

• Покрывать автотестами имеет смысл уже стабильный и нечасто меняющийся функционал. Есть такой на проекте? Хорошо. Все меняется через каждые 5 минут? Нууу, сами понимаете.

• Мало один раз поднять автотесты, их надо еще поддерживать. И мы опять возвращаемся к теме бюджетов и ресурсов.

Итак, это основные, на мой взгляд, шесть вариантов сокращения регрессионных проверок. Каждый можно применять обособленно от других, но можно (и нужно, как мне кажется) комбинировать.

Что нам может помочь еще?

Во-первых, хорошая практика — иметь под рукой минимально необходимый набор проверок самых основных вещей в продукте. Если есть сомнения, какой объем проверок нужен — начните с базовых, а дальше сориентируйтесь по оставшемуся времени.

Во-вторых, индивидуальное определение тестового набора для каждого релиза. Если мы катим быстрый хотфикс, в котором исправили один экран — скорее всего, можно пренебречь проверками всего остального. В релиз вошло 100500 задач, да еще и смежные системы задействованы? Да уж, простым смоуком мы в таком случае не обойдемся — надо гнать максимально полный регресс. Трогали только один модуль — базовые проверки + регрессим модуль.

В-третьих, можно проводить условную «инвентаризацию» по функционалу раз в какой-то период. Как в прошлом варианте, только помимо доработанного модуля еще какой-нибудь (например, самый проблемный или же тот, который дольше всех не проверяли). Кстати, это можно делать как в рамках регрессионного тестирования, так и присовокуплять к тестированию каких-то доработок фичи, или же просто в рамках каких-то регулярных QA-активностей. Так вы сможете существенно снизить количество слепых зон, при этом не сильно увеличивая регресс.

В-четвертых, часть регрессионного тестирования можно делегировать представителям бизнеса и/или дизайнерам в рамках проведения авторского надзора. Всегда существуют риски, что в процессе разработки кто-то кого-то не так понял, а на авторском надзоре от бизнеса это достаточно быстро выясняется. Из минусов — большая стоимость переделок по замечаниям. Если говорить про авторский надзор от дизайнера, то он позволяет QA-специалистам тратить меньше времени на pixel perfect и на нефункциональные проверки (например, на UX-тестирование). Главное —не злоупотреблять этим и заранее проговорить зоны ответственности каждого.

Резюмирую

Пожалуй, это все, что я хотела рассказать сегодня про работу с регрессионным тестированием. В заключение хочу подчеркнуть несколько пунктов:

1. Держите голову в холоде, ноги в тепле, а регрессионную модель — в порядке.

2. Соблюдайте баланс между обилием проверок, их необходимостью и достаточностью.

3. Подбирайте тестовые регрессионные наборы индивидуально для каждого релиза (или типизируйте их).

4. Автоматизируйте все то, что можно автоматизировать.

5. Делегируйте то, что можно делегировать.

6. И вообще, делайте хорошо — плохо не делайте :-)

А что помогало вам сократить регрессионное тестирование с сохранением нужного уровня качества?