В чем разница между приемочным и регрессионным тестированием?

Давай разжую, в чём разница, а то у некоторых в голове уже каша, ёпта. Представь, что ты заказал у прораба баню. Вот он её построил, выкатывает тебе ключи и говорит: «Принимай работу!»

Приемочное тестирование (UAT) — это когда ты, как хозяин, приходишь и начинаешь проверять. Топишь печь, паришься, льёшь квас на каменку — в общем, делаешь всё, для чего баню и строил. Цель одна: валидация. То есть, правильную ли баню тебе, сука, построили? Та ли, что в договоре? Или вместо парной у тебя холодильник получился? Выполняет ли она своё главное предназначение — греть и чтоб душа радовалась? Вот это и есть UAT. Делает его заказчик (ты) или твой доверенный представитель (бизнес-аналитик, например).

Регрессионное тестирование — это совсем другая история. Допустим, через месяц ты прорабу звонишь: «Мужик, тут у меня полок треснул, почини!». Он приезжает, меняет полок. И вот тут начинается регрессия. Потому что после его «ремонта» может оказаться, что:

1. Печь перестала топить (ёперный театр!).
2. Дверь в предбанник не закрывается.
3. Вода из шайки теперь выливается сама по себе, будто её кот, сука, собака, опрокинул.

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

Короче, таблица, чтоб вообще мозг не взорвался:

Пример из жизни, чтобы стало совсем ясно, как дважды два:

Допустим, у нас интернет-магазин.

• Приемочный тест (заказчик проверяет фичу):

  • Сценарий: «Хочу ввести промокод SUMMER10 в корзину и получить свои 10% скидочки».
  • Действие: Продукт-оунер (или ты) заходит, тыкает в корзину, вводит этот самый промокод и смотрит — упала ли цена. Если упала — афигенно, принято! Если нет — иди ты нахуй, разработчик, переделывай! Всё просто и по делу.

• Регрессионный тест (QA страхует от пиздеца):

  • Сценарий: Через месяц программисты добавили возможность оплаты подарочными картами. Классно? Классно. Но теперь надо проверить, не сломали ли они при этом всё остальное, я тебя умоляю. Запускаем автотесты, которые проверяют:
    1. Старый промокод SUMMER10 всё ещё работает? (Вдруг его хуй с горы снёс?)
    2. А если я попробую и промокод, и подарочную карту впихнуть, система не пизда рулю? Ведёт ли себя как задумано?
    3. Оформление заказа вообще без всяких акций — живое ещё?
  • Действие: QA не сидит и не тыкает это всё руками каждый раз. Он жмёт кнопку, и пачка автотестов сама всё прогоняет. Нашёл баг — кричит: «Э, шалава, что ты там накодил? Регресс повалился!».

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