Регрессионное тестирование часто опирается на один и тот же набор сценариев, и со временем это превращается в проблему: привычные проверки перестают находить новые дефекты, а часть функциональности надолго выпадает из поля зрения команды. Возникает так называемый парадокс пестицида — снижение эффективности неизменных тестовых сценариев с течением времени. Название возникло по аналогии с сельскохозяйственными вредителями, которые вырабатывают устойчивость к постоянно применяемым веществам.
Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.
Я поделюсь техническими деталями реализации, логикой распределения весов и результатами нашего эксперимента. Спойлер: ожидания не во всём совпали с реальностью — но именно этот опыт оказался для нас самым ценным.
Какая перед нами стояла задача
Как тестировщики, мы стремимся выстраивать процессы тестирования так, чтобы минимизировать риск пропуска багов в продакшен. Регрессионное тестирование — неотъемлемая часть этого процесса. Это способ подтверждения того, что недавние изменения кода не сломали функциональность приложения.
Однако на практике в регресс часто попадает фиксированный набор тест‑кейсов, который не меняется годами. Именно здесь и возникает парадокс пестицида, о котором я уже говорила выше. Это один из семи базовых принципов тестирования. Его суть проста: если из раза в раз прогонять одни и те же сценарии, со временем они перестают находить новые дефекты.
Продукт обрастает новым кодом, а наш привычный набор тестов работает хуже и хуже — баги уже выработали к нему «иммунитет». При этом значительная часть сценариев автоматизируется, из‑за чего некоторые проверки со временем полностью выпадают из поля зрения при ручных прогонах.
В итоге возникает серьёзный риск: отдельные части сервиса могут не проверяться очень долго, и мы теряем контроль над тем, что там происходит. Опыт и статистика показывают, что пользователи редко репортят о проблемах, если те не блокируют работу приложения, — чаще они находят обходной путь или просто перестают пользоваться продуктом.
На конец 2025 года, когда мы взялись валидировать тестовую базу с помощью системы и находить баги в «забытых» тест‑кейсах, в базе было около 1000 тест‑кейсов. При этом около половины входило в регресс, и из них же более 80% — это автоматизированные регрессионные сценарии.
Мы решили добавить в регресс «забытые» тест‑кейсы, ранжируя их с помощью системы весов. Поскольку ручной отбор отнимает слишком много времени у дежурного, мы выбрали путь автоматизации, тем более что технически задача оказалась вполне реализуемой в короткие сроки.
Какие данные и инструменты нам понадобились
Все тест‑кейсы у нас хранятся во внутренней TMS (Test Management System). В каждом кейсе зафиксирована вся необходимая история:
резолюции и даты прогонов;
статус автоматизации;
информация о правках и авторах изменений;
функциональность.
Поскольку база данных тест‑кейсов внутри компании открыта, мы можем обращаться к ней напрямую. Это значительно упрощает задачу: мы собираем сырые данные и сохраняем их в отдельную таблицу БД уже в агрегированном виде.
Для финальной обработки и визуализации мы используем BI‑инструмент DataLens. С помощью внутренних формул мы построили сводную таблицу (чарт), в которой рассчитывается итоговый вес каждого сценария. После этого мы ранжируем их — от самых «забытых» и потенциально проблемных до самых свежих.
Вот весь флоу работы системы:
Что под капотом: логика ранжирования
Мы не стали изобретать велосипед с нуля. Наш подход опирается на концепцию History‑Based Test Case Prioritization (TCP). Исследования показывают, что исторические данные о поведении теста — отличный предиктор его полезности в будущем.
Обычно TCP применяют для сложной фильтрации автотестов в CI/CD‑пайплайнах. Нам же нужен был легковесный и прозрачный инструмент для ручного регресса — без машинного обучения, с понятной математикой и с возможностью быстрой сборки в BI.
После выгрузки сырых данных из TMS мы рассчитываем итоговый приоритет каждого тест‑кейса — вес от 0% до 100%. В формуле учитываются пять ключевых факторов:
Время с последнего прогона (вес 50%). Это самый значимый критерий: чем дольше кейс не проходили вручную, тем выше его приоритет. Максимальный балл получают тесты, которые не запускались более 180 дней. Если тест не запускали вообще (ситуация Cold Start), система присваивает ему виртуальное значение в 999 дней, что мгновенно выводит его в топ списка.
История провалов (вес 30%). Мы анализируем процент неудачных прогонов за последние 90 дней. Если тест регулярно «падает» при ручной проверке, это прямой сигнал для дежурного: такой сценарий нужно прогонять чаще стабильных.
Частота прогонов (вес 10%). Учитывается количество запусков в разрезе конкретного функционального модуля. Чтобы крупные фичи с сотнями проверок не вытесняли из рейтинга маленькие модули, мы сглаживаем распределение — берём квадратный корень от общего количества прогонов.
Общая успешность (вес 10%). Учитывается глобальный Success Rate тест‑кейса за всё время. Если данных по кейсу ещё нет, используем значение по умолчанию — 0,5.
Поправка на недавние проверки. Чтобы в выдаче у дежурного не дублировались одни и те же пограничные кейсы каждую неделю, мы добавили «штрафной коэффициент»: если тест запускался в последние 30 дней, его приоритет искусственно снижается (чтобы бороться с тем самым парадоксом пестицида).
В результате в DataLens формируется таблица с рейтингом. Чтобы дежурному было проще ориентироваться, мы перевели числовой Success Rate в понятные текстовые статусы:
Never run — тест ещё ни разу не запускался.
Unstable — успешность ниже 70%.
Stable — от 70 до 90%.
Very stable — выше 90%.
Применение и результаты
Чтобы внедрить систему в рабочий процесс, мы настроили робота. Через API он забирает из DataLens список тест‑кейсов с наивысшим приоритетом и автоматически добавляет их к текущему регрессионному набору. В итоге дежурный получает единый список, состоящий из двух частей:
Фиксированные кейсы проекта (базовый регресс).
Динамические рекомендации, подобранные нашей системой весов.
Результаты эксперимента оказались неожиданными. Мы рассчитывали обнаружить множество «забытых» багов в старой функциональности, но на практике столкнулись с масштабной проблемой актуальности проверок.
Вот как распределилась статистика по рекомендованным тест‑кейсам:
46% кейсов оказались валидными, но требовали серьёзного обновления (устарели скриншоты, шаги или ожидаемый результат).
18% тестов пришлось отправить в архив — они полностью потеряли смысл из‑за изменений в продукте.
24% тестов действительно помогли найти баги.
32% багов было обнаружено среди группы Never run (тесты, которые ранее никогда не прогонялись вручную).
За время эксперимента мы успели «подсветить» и проверить 11 различных функциональных модулей продукта, до которых раньше не доходили руки.
Метрики собраны за 3–4 месяца с начала внедрения системы:
Могу с уверенностью сказать, что результаты внедрения в регрессы рекомендованных тест‑кейсов нас приятно порадовали (в каком‑то смысле, если вообще можно радоваться багам и неактуальным тест‑кейсам), а значит, система приносит пользу нашим процессам тестирования.
Итак, главный профит, который мы получили:
Актуализация базы. Мы выявили и обновили или архивировали множество тест‑кейсов, которые работали не так, как задумано, или не работали вовсе.
Проверка гипотез и победа над парадоксом. Мы на практике доказали, что старые тесты теряют эффективность. В сценариях, которые никогда не прогонялись вручную (те самые Never run) или были давно забыты, плотность багов оказалась почти в два раза выше, чем в среднем по привычной выборке (16% против 9%). Смена фокуса проверок сработала.
Снижение когнитивной нагрузки. Дежурному больше не нужно мучительно выбирать, «что бы ещё проверить сегодня», — система сама подкидывает приоритетные задачи.
Дальше хочется развивать наш регресс в сторону полноценного Data‑Driven‑тестирования. В идеале мы планируем научить систему рекомендовать кейсы не только на основе того, что они старые, но и на основе Impact Analysis. То есть автоматически подбирать проверки, анализируя изменённый разработчиками код в пул‑реквестах и информацию в задачах.
А как вы в своих командах боретесь с замыливанием глаза и парадоксом пестицида? Накидываете рандомные проверки в регресс руками, пишете свои скрипты или полностью доверяете автотестам? Буду рада почитать в комментариях про ваш опыт.