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