Уже задрало слышать, что «Регрессионное тестирование — это когда мы заново всё тестируем».
Кагбэ, да, но тогда почему это называется «Регрессионное тестирование», а не «Перетестировывание всего заново»?
«Заново всё тестируем» — это не объяснение сути обсуждаемого феномена! Это лишь описание внешних признаков сего феномена. Так ребенок может объяснить, что такое автомобиль, не понимая, как и почему вот это вот всё работает. Вроде «Автомобиль — это когда папа за рулём, он едет на работу, а я в детский сад, и мне удобно в нём сидеть». Всё правильно же?!
Кроме термина регресс еще есть термин регрессия — сам по себе термин неоднозначный. Это бывает и в психологии, и в финансовой аналитике, и это разные феномены ВААПЩЕ.
Значитца, так. В википедии правильно указана суть термина «Регрессионное тестирование» (англ. regression testing, от лат. regressio — движение назад), но дальнейшее объяснение недостаточно адекватно. Дитячее оно.
Давайте объясняться по-взрослому.
Есть понятие Прогресс.
А есть понятие Регресс — обратная сторона прогресса.
Любая/каждая система по мере накопления функциональных возможностей развивается (прогрессирует). Это круто.
Например, какая-нибудь политическая партия: появляется в одном городе, затем, если начинает расти, открывает филиалы в соседних огородах, потом в соседних районах, областях, уездах, губерниях, выходит на уровень реальной политической силы, выходит в парламент, в космос, переезжает всем штабом в Дондюшаны и курит там кальян из зеленой травы, бо дальше развиваться некуда, мир завершается Дондюшанами.
Любая ERP-система развивается по тому же принципу — все больше информации собирается и учитывается по каждому чиху. Отчёты все красочнее, объемнее, в запросах все больше ЕСЛИ и НО НЕ и КРОМЕ.
Однако увеличение функциональности незаметно приносит и увеличение взаимосвязей между функциями.
Партия начинает управляться на местах все более автономно, глава партии уже не может, как когда-то, самостоятельно решать, что нужно делать, а что не нужно. Уже приходится перед принятием решения договариваться с самыми влиятельными лидерами региональных отделений. Уже приходится учитывать чужие интересы. Уже невозможно быть уверенным в том, что какое-то приказание, выданное в регионы, дойдет до каждого, и будет выполняться именно так, как было задумано.
Это и есть регресс.
Чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование.
И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения.
Со стороны это выглядит как «Внесли новый функционал — обязательно перетестировываем всё!» Словно тестировщики в тысячный раз прогоняют уже существующие тесты, вот и всё.
Не всё. Этого недостаточно.
Проблема регресса для тестировщиков намного серьезнее — мы каждый раз не знаем, что принесёт с собой новая функциональность в системе. И каждый раз надо предположить/узнать/протестировать новые взаимодействия в системе, а не тестировать только новые функции в изоляции от остальных.
Смысл просто гонять старые тест-кейсы, если они были написаны без учета новых ситуаций?
Со временем старый функционал начинает плотно пересекаться с новым — и надо заново расчехлять аналитику, заново выявлять новые ситуации, которые могут возникнуть, заново писать тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты…
А «в интеграции» бытуют такие баги, о которых и не догадаешься, рассматривая функцию логина по-отдельности от остальных функций…
Поэтому регрессионное тестирование — нескончаемый кошмар, вообще-то… И выяснение «не наступил ли регресс» (внимание, не путать с «не наступила ли регрессия«) — постоянная задача, которую с какого-то момента необходимо постоянно решать.
В любом проекте с какого-то момента начинается уже не улучшение продукта, а борьба за «чтобы оно всё еще продолжало работать, как раньше«… с постоянным выяснением, а не наступил ли регресс из-за усложнения системы.
В начале проекта ВООБЩЕ нет необходимости думать про регрессионное тестирование. В начале проекта даже тест-кейсами особо заморачиваться нет смысла.
Но чем дальше влез в лес…
«а борьба за “чтобы оно всё еще продолжало работать, как раньше“…» — как точно сказано, с каждой новой версией и изменении функциональности, ломаются старые связи и программисты не заморачиваются по этому поводу. Приходится тестировщикам проверять не поломалось ли то, что хорошо работало. В результате все сломано, куча багов, и тестировщик без работы не останется…
Плохо, если не заморачиваются.
Но даже если и заморачиваются, то не всегда качественно заморачиваются.
Регрессионное тестирование — это то, что ждет любого тестировщика в будущем и как же жалко, что не все подготавливаются к этой встрече.
давно не было такого хорошего выдержанного вина.
Леша, пиши ещё. 🙂
Уведомление: DOU QA дайджест #12: О мобильном тестировании, автоматизации и инструментах - Radio QA
Уведомление: Как будут учить тестировщиков в Киеве в 2026 году | QA — грамотно
Уведомление: Regression is my profession! | Normal testing