Что такое регрессионное тестирование и когда его применять?
Что проверяют
Отличаете ли вы регрессию от проверки исправления и понимаете ли, как выбирать объём.
Как отвечать
Регрессионное тестирование это повторная проверка уже работавшей функциональности после изменений, чтобы убедиться, что она не сломалась.
Сразу отделите соседние понятия:
- проверка исправления (confirmation testing): убедиться, что конкретный дефект починен. Это про новое поведение;
- регрессия: убедиться, что починка ничего не задела рядом. Это про старое поведение;
- дымовое тестирование: быстрый широкий проход по критичным сценариям, чтобы понять, годится ли сборка для тестирования вообще. Оно неглубокое, регрессия глубокая.
Когда применять: после исправления дефектов, после новой функциональности, после рефакторинга (особенно после него, потому что поведение меняться не должно вовсе), после обновления зависимостей, версии языка или окружения, после слияния веток и всегда перед релизом.
Как выбирать объём, потому что полный прогон всего почти никогда не влезает в срок:
- по влиянию: анализ, какие модули затронуты изменением, включая общие компоненты и данные;
- по риску: критичные для бизнеса сценарии проверяются всегда, независимо от области правки;
- по истории дефектов: места, где ломалось раньше, ломаются снова;
- приоритизация набора: часть кейсов гоняется на каждой сборке, часть еженедельно, полный набор перед релизом.
Главный ответ на вопрос «как успевать» это автоматизация: регрессия по природе повторяемая и однообразная, то есть идеальный кандидат. Ручной остаётся исследовательская часть и то, что дорого автоматизировать.
За чем следить в автоматизированном наборе: время прогона и нестабильные тесты. Набор, который иногда краснеет без причины, перестают читать, и он теряет смысл.
Где спотыкаются
Путают регрессию с проверкой исправления.
Считают дымовой набор разновидностью регрессии.
Гоняют полный набор всегда и не успевают к релизу.
Терпят нестабильные тесты вместо того, чтобы чинить или изолировать их.