Регрессионное тестирование - это проверка того, что после изменения по-прежнему работает то, что работало раньше. Не само изменение, его проверяют, когда пишут, а всё вокруг него: то, чего никто не трогал и на что никто не рассчитывал повлиять.

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

Почему этим занимаются отдельно

У каждого изменения радиус поражения шире, чем его диф. Общая функция, колонка в базе, которую читают в шести местах, правило CSS, оказавшееся несущим для страницы, которую автор ни разу не открывал.

Сбой, который это предотвращает, конкретный и дорогой: релиз, который чинит один сообщённый баг и заводит два несообщённых. Они обходятся куда дороже исходного, потому что их никто не ищет. Сообщённого бага кто-то ждал; новые находят клиенты, через несколько дней, не понимая, что изменилось.

Что на самом деле перепроверять

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

Стоит перепроверять почти при любом изменении:

  • Пути, которые приносят деньги. Регистрация, вход, оформление заказа, оплата. Всё остальное может подождать до понедельника, эти - нет.
  • То, что изменение действительно затрагивает, плюс всё, что делит с ним функцию, таблицу или шаблон.
  • Всё, что ломалось раньше. Дефект, вернувшийся однажды, вернётся снова, и баг, ушедший в регресс, - лучший аргумент за постоянный тест.
  • Интеграции, которыми вы не управляете. Всё, что обращается к чужому сервису, падает по причинам, никак не связанным с вашим релизом.

Не каждый раз стоит: редко открываемые экраны настроек, административные инструменты на двух пользователей, всё, чей отказ кто-нибудь заметит и сообщит без последствий.

Где заканчивается смоук-тест и начинается это

Их задают в разные моменты, и отвечают они на разные вопросы.

Смоук-тест
Стоит ли эту сборку вообще тестировать? Пять проверок, минуты, запускается первым, на каждой сборке
Регрессионный тест
Перестало ли работать то, что работало раньше? Сотни проверок, дольше, запускается, когда сборка себя показала

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

Руками или автоматически

Автоматизация - очевидный ответ и неполный.

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

Оставьте человека для того, о чём скрипт судить не может. Вёрстка неправильная или просто другая. Есть ли смысл в сообщении об ошибке. Ощущается ли сценарий по-прежнему рабочим. Сравнение скриншотов скажет вам, что сдвинулись одиннадцать пикселей; оно не скажет, что кнопка теперь ниже первого экрана на самом распространённом ноутбуке среди ваших пользователей.

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

Как набор портится

Тремя способами, все три обычные, и каждый заканчивается тем, что набор перестают замечать.

Он становится медленным. Набор на девяносто минут гоняют по ночам, а не на каждое изменение, и на регрессии, найденной наутро, уже что-то построено.

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

Он только растёт. Тесты добавляют на каждый дефект и не убирают ни за чем, пока половина набора не начинает покрывать поведение, которого у продукта больше нет. Удалять тесты - часть ухода за ними.

Когда регрессия всплывает

Упавший регрессионный тест - это ненаписанный отчёт об ошибке, и начинается он с большего, чем получает большинство отчётов: вы знаете, что раньше работало, и часто знаете, в каком именно релизе перестало.

Так и напишите. «Работало в 4.2.0, падает в 4.3.0» превращает расследование в диф. Это самая полезная фраза в отчёте о регрессии и та, которую чаще всего опускают, потому что пишущий считает, что это и так все знают.

Если на регрессию наткнулись руками, а не поймал набор, теряется обычно контекст.

Session Replay

Бесплатное расширение для Chrome. Один клик на странице, которая ведёт себя не так, захватывает скриншот, консоль и сетевой журнал и отдаёт вам ссылку, которую можно вставить в задачу.

Установить расширение

Остальное, что нужно хорошему отчёту, есть в руководстве по отчётам об ошибках, и в его шаблоне есть строка для версии, в которой всё работало.

Коротко

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