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