Срок регрессионной проверки сократили вдвое. Как определить, какие тесты исключить в первую очередь?
В первую очередь исключают не «самые длинные» тесты, а проверки с наименьшим остаточным риском: низким влиянием отказа, небольшой вероятностью дефекта и слабой связью с изменённой областью. Критические пользовательские и бизнес-сценарии, затронутые изменениями, оставляют даже при высокой стоимости выполнения.
Решение должно быть явным: команда фиксирует критерии отбора, покрытые риски и принятые ограничения. Сокращение набора тестов уменьшает время проверки, но повышает вероятность пропустить дефект, поэтому остаточный риск должен быть согласован с ответственными за продукт.
Риск-ориентированное тестирование появилось как практический ответ на ограниченность времени, людей и вычислительных ресурсов. Полностью проверить сложную систему обычно невозможно, поэтому тестирование направляют туда, где ошибка нанесёт наибольший ущерб или наиболее вероятна.
Такой подход заменяет механическое стремление выполнить все тесты управлением рисками. Набор проверок становится зависимым от контекста: для платёжной операции и второстепенного визуального элемента допустимы разные глубина и приоритет тестирования.
При сокращении регрессии случайное удаление тестов создаёт ложное ощущение экономии. Можно быстро освободить время, но одновременно убрать единственные проверки критического сценария или области, изменённой последним релизом.
Для выбора нужны как минимум четыре фактора: влияние отказа, вероятность дефекта, степень изменений и стоимость проверки. Ошибка в расчёте платежа имеет высокий ущерб даже при небольшой вероятности, а дефект в редко используемой функции может иметь меньший приоритет.
Сначала составляют список рисков релиза и связывают с ними тесты. Затем оценивают каждый тест по нескольким признакам:
В первую очередь сохраняют проверки критических бизнес-потоков, безопасности, целостности данных, интеграций и изменённых компонентов. Исключать или откладывать разумнее дублирующие, низкорисковые и слабо связанные с релизом проверки, особенно если их риск уже покрыт другими тестами.
Важно различать удаление и отложенное выполнение. Тест можно временно не включить в текущую регрессию, но оставить в полном наборе и назначить срок возврата, иначе временная оптимизация превратится в постоянную потерю покрытия.
Риск-ориентированный отбор не означает, что тесты с низким приоритетом никогда не выполняются. Их проверяют позже, при наличии времени, в полном регрессионном цикле или перед изменениями соответствующей области.
Ключевой компромисс состоит в выборе между скоростью обратной связи и полнотой обнаружения дефектов. Чем меньше набор, тем выше остаточный риск; поэтому решение следует документировать, а для критичных систем дополнительно получать явное согласование владельца продукта или другой ответственной стороны.
В интернет-магазине перед выпуском изменили расчёт доставки, но время регрессии сократили с восьми до четырёх часов. Полный набор включал проверки каталога, авторизации, корзины, оплаты, расчёта доставки, уведомлений и административных отчётов.
Рассматривались два варианта. Первый — оставить тесты, которые выполняются быстрее всего; он даёт больше пройденных проверок, но игнорирует ущерб от дефектов. Второй — запускать только тесты изменённого компонента; это быстрее, однако не учитывает ошибки на стыках с корзиной, оплатой и уведомлениями.
Выбрали приоритизацию по риску: сохранили основные сценарии оформления заказа, разные способы доставки, граничные условия расчёта, оплату, сохранение заказа и интеграционные проверки. Редко используемые отчёты и дублирующие проверки каталога перенесли в отложенный набор.
Такой выбор дал меньшее количество выполненных тестов, но сохранил покрытие сценария с высоким бизнес-ущербом и всех основных зон изменений. Отложенные проверки не удалили: их включили в ближайший полный регрессионный прогон.
Нет. Степень изменения — лишь один фактор. Небольшое изменение может повлиять на критичную общую библиотеку, базу данных или интеграционный контракт и затронуть множество функций.
Нужно учитывать влияние отказа, вероятность дефекта, зависимости, реальное использование функции и качество предыдущих проверок. Поэтому область без прямых изменений иногда получает высокий приоритет из-за транзитивного воздействия через общие компоненты.
Следует использовать качественную шкалу, например низкий, средний и высокий риск, и явно фиксировать основания оценки. Полезными источниками служат история дефектов, сложность изменений, затронутые интеграции, частота использования и критичность бизнес-процесса.
Неточная, но прозрачная оценка лучше произвольного выбора. Её можно пересмотреть после получения новой информации: обнаруженного дефекта, изменения требований или уточнения последствий отказа.
Само по себе стабильное прохождение не доказывает, что тест больше не нужен. Оно может означать отсутствие дефектов, но также слабую чувствительность проверки, неизменность входных данных или недостаточную наблюдаемость результата.
История успешных прогонов может уменьшить оценку вероятности дефекта, но не должна автоматически обнулять приоритет. Если сценарий критичен или затронут изменениями, его сохраняют, даже когда предыдущие запуски не выявляли проблем.