Кто отвечал за выполнение регрессионного тестирования?

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

Представь картину: выпускаем мы фичу. Всё, блядь, протестировано, работает. А потом бац — через месяц выясняется, что кнопка «Купить» теперь открывает не корзину, а гороскоп на неделю. Это и есть регресс, ёпта! То есть, пока мы новый функционал пилили, старый и работающий — нечаянно положили. И чтобы этого не было, нужна система, а не просто «ой, кажется, всё норм».

Так вот, распределяется эта почетная обязанность так:

• Автоматизатор (Automation QA) — это наш главный по таблеткам. Его задача — накодить таких роботов-тестеров, которые будут сами, без напоминаний, после каждого обновления пробегаться по основным сценариям и орать, если что-то поехало. Он отвечает за эту автоматическую регрессионную портянку, которая вшита прямо в процесс сборки. Без него — пиздец и ручной труд до скончания веков.
• Ручной тестировщик (Manual QA) — это наш специалист по тонкой настройке и там, где робот — тупой. Автоматизация не всё может, ей, например, похуй на то, что кнопка съехала на три пикселя вправо или что анимация дергается. Вот ручной товарищ берет и выборочно, глазами и руками, проверяет эти сложные штуки, а также все исправленные баги — потому что фиксим один, а ломаем два, это святое.
• Разработчик (Dev) — а этот чувак вообще должен быть первым заслоном. Пока он код пишет, он же юнит-тесты и интеграционные тесты должен гонять. Это как фундамент: если он кривой, то всё здание (наш регресс) потом будет лечиться аспирином от менингита.

Как это в железе выглядит (на примере GitLab CI):

Смотри, вот упрощенная схема пайплайна. Код — святое, его не трогаем.

stages:
  - build
  - unit-test
  - deploy-staging
  - regression

# Этап 1: Разработчик защищает код юнит-тестами
unit-test:
  stage: unit-test
  script:
    - mvn test # Запуск юнит-тестов

# Этап 2: Автоматизированный регресс на staging
api-regression-suite:
  stage: regression
  script:
    - echo "Запуск API регрессионных тестов"
    - npm run test:api:regression
  artifacts:
    reports:
      junit: reports/api-regression-report.xml

ui-smoke-suite:
  stage: regression
  script:
    - echo "Запуск UI smoke-тестов (часть регресса)"
    - npx playwright test --grep @smoke

Видишь? Сначала разработчик свои тесты прогоняет (этап unit-test). Потом, когда всё собралось и задеплоилось на тестовый стенд (staging), автоматом запускаются регрессионные проверки (regression): и API, и UI. Если там всё зелёное — можно дальше думать. Если красное — все, пиздец, пайплайн падает, и все бегут смотреть, кто что сломал.

А теперь стратегия, или «Когда и какую дубину включать»:

1. Полный регресс (раз в квартал/перед мега-релизом). Это, блядь, всеобщая мобилизация. Запускается весь автопарк тестов, от и до. Плюс ручные тестировщики берут чек-листы и начинают ползать по всему приложению, как тараканы по ночной кухне. Цель — убедиться, что за последние три месяца мы не наворотили такого, что система думает, что она — нейросеть для рисования котиков.
2. Частичный/санити-регресс (после КАЖДОГО билда). Это наша ежедневная рутина. Гоняются не все тесты, а только самые критические (smoke) и те, что завязаны на изменённых модулях. Логика простая: если сломалось что-то базовое — «войти», «купить», «оплатить» — то дальше можно даже не смотреть, всё, приехали. Экономит время, нервы и сервера.
3. Регресс на фиксы. Это священный ритуал. Нашли баг, пофиксили. Так вот, задача QA — не просто проверить, что баг пофикшен. Нет! Его задача — проверить, что баг не вернулся как зомби, и что, фикся эту одну хуйню, разработчик не разнёс к хуям собачьим пять соседних функций. Это обязательно и часто вручную.

Короче, суть в чём: основную, рутинную, тупую работу по отлову «внезапно сломалось» должна делать автоматизация. А живой человек — это дорогой и ценный ресурс, который должен тратить мозги на сложные кейсы, а не тыкать сто раз в одни и те же кнопки. Вот так, блядь, и выживаем.