Привет, Хабр! Меня зовут Ксения Сергеева, я 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-тестирование). Главное —не злоупотреблять этим и заранее обговорить зоны ответственности каждого.
Резюмирую
Пожалуй, это все, что я хотела рассказать сегодня про работу с регрессионным тестированием. В заключение хочу подчеркнуть несколько пунктов:
Держите голову в холоде, ноги в тепле, а регрессионную модель — в порядке.
Соблюдайте баланс между обилием проверок, их необходимостью и достаточностью.
Подбирайте тестовые регрессионные наборы индивидуально для каждого релиза (или типизируйте их).
Автоматизируйте все то, что можно автоматизировать.
Делегируйте то, что можно делегировать.
И вообще, делайте хорошо — плохо не делайте :-)
А что помогало вам сократить регрессионное тестирование с сохранением нужного уровня качества?
