Используете ли вы отдельную ветку разработки для тестирования

Что проверяют

Как в вашей команде устроен путь задачи от кода до релиза и понимаете ли вы, что именно тестируете: ветку, сборку или стенд. Следом обычно спрашивают, как вы убеждаетесь, что в прод уходит то же, что вы проверили, и кто решает, что задача готова к слиянию.

Как отвечать

Это вопрос про ваш процесс, поэтому опирайтесь на свой опыт, но покажите, что знаете альтернативы:

• ветка под каждую задачу: feature-ветка разворачивается на отдельный стенд (review app, динамическое окружение в Kubernetes), вы тестируете её до слияния в main. Самый удобный вариант для QA: баги находятся до того, как попали в общую ветку;
• GitFlow: общая develop, из неё release/*, где идёт регресс и стабилизация, исправления вливаются обратно. Подходит для релизов по расписанию, мобильных приложений, коробочных продуктов;
• trunk-based: короткие ветки, частые слияния в main, незаконченное прячется за feature flags. Отдельной тестовой ветки нет, качество держат автотесты в пайплайне и проверка на stage.

Сильная мысль для ответа: тестировать нужно конкретную сборку, а не ветку вообще. Артефакт собирается один раз, и тот же образ с тем же тегом продвигается с test на stage и в прод. В отчёте о тестировании фиксируется версия сборки или хэш коммита.

Отдельно скажите, где живут автотесты: в репозитории продукта рядом с кодом, тогда они ветвятся вместе с ним, или в отдельном репозитории, тогда нужно договориться, какая версия тестов соответствует какой версии продукта.

Приведите свой пример: какая схема была, какие проблемы она создавала, что меняли. Если процесс выбирали не вы, так и скажите, и объясните, что предложили бы сами и почему.

Где спотыкаются

Описывают долгоживущую ветку testing, куда сливают всё подряд. Задачи блокируют друг друга, конфликтов много, а в main потом уходит набор изменений, который в таком виде никто не проверял.

Не могут ответить, какую именно версию тестировали. «Что-то со стенда» не ответ, когда в проде нашёлся баг.

Приписывают процессу красивые проценты вроде «дефектов стало на 40% меньше», которых никто не считал. Если цифр нет, лучше рассказать, какие конкретные проблемы схема убрала.