Какие дополнительные проверки по сборке используются
Что проверяют
Понимаете ли вы, что происходит со сборкой до того, как она попадёт к вам на ручное тестирование, и какие проверки в CI отсекают брак раньше. Следом обычно спрашивают, что из этого вы настраивали сами и что делаете, если сборка «зелёная», но сломана.
Как отвечать
Опишите конвейер по порядку, от дешёвых проверок к дорогим:
- статический анализ и линтеры: SonarQube с порогом качества (quality gate), ESLint, Checkstyle. Сборка падает, если новые замечания выше порога;
- юнит-тесты и покрытие: запускаются на каждый коммит, покрытие считает JaCoCo или аналог. Важнее порог на новый код, а не общая цифра по проекту;
- проверка зависимостей: поиск известных уязвимостей в библиотеках и образах (OWASP Dependency-Check, Snyk, Trivy), проверка лицензий;
- smoke-тесты: быстрый прогон ключевых сценариев сразу после развёртывания сборки на стенд. Не прошли, дальше сборку не берём;
- интеграционные и API-тесты: проверка контрактов между сервисами, часто с поднятием зависимостей в Testcontainers;
- регрессия: автотесты UI и API ночью или перед релизом, ручная регрессия по чек-листу на то, что не автоматизировано;
- артефакт: версия и номер сборки соответствуют коммиту, подставлен конфиг нужного окружения, размер артефакта не вырос вдвое без причины;
- нефункциональные проверки: нагрузочный прогон на JMeter, k6 или Gatling и динамический скан безопасности OWASP ZAP. Обычно по расписанию или перед релизом, а не на каждый коммит.
Хорошо прозвучит, если вы назовёте, на каком шаге сборка блокируется, а где проверка только предупреждает.
Где спотыкаются
Перечисляют виды тестирования из учебника без привязки к конвейеру. Интервьюер спрашивает про реальный процесс, лучше описать свой проект.
Путают smoke и sanity или называют полную регрессию проверкой каждой сборки. На каждый коммит она обычно слишком дорога.
Не упоминают, кто реагирует на упавшую проверку. Проверка, которую все привыкли игнорировать, ничего не проверяет.