Как предотвращать конфликты при совместной работе над тестами и методами?

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

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

Как отвечать

Технические конфликты:

• маленькие изменения: короткие ветки, небольшие пулл-реквесты, регулярный rebase на основную ветку. Конфликт слияния растёт вместе с возрастом ветки;
• распределение зон: в трекере видно, кто какой модуль покрывает, тест-кейсы в TMS (Test IT, Allure TestOps, Qase) закреплены за областями, и двое не пишут один и тот же тест;
• единый стиль: форматтер и линтер (Prettier, Black, Spotless) в pre-commit и в CI, тогда конфликтов из-за отступов и порядка импортов просто нет;
• изоляция тестовых данных: каждый тест создаёт свои данные с уникальным префиксом и убирает за собой. Общие учётки и заказы дают конфликты уже на прогоне, особенно параллельном.

Конфликты между людьми:

• договорённости письменно: спорный подход (например, где хранить локаторы) решается один раз и фиксируется в README или ADR, а не заново на каждом ревью;
• ревью по делу: комментарий к коду, а не к автору, с объяснением почему;
• эскалация: если за разумное время договориться не вышло, решает лид, и команда принимает решение.

Дальше свой пример по STAR: ситуация, ваша роль, что сделали, результат. Цифры берите реальные. Если серьёзных конфликтов не было, скажите честно и расскажите о небольшом разногласии и о том, как вы его закрыли.

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

Отвечают только про Git или только про отношения. Интервьюер ждёт обе стороны или хотя бы уточняющий вопрос.

В примере виноватым выходит коллега, а вы всегда правы. Это читается как неумение принять чужую точку зрения, лучше показать, где вы уступили.

Предлагают еженедельные встречи как главный способ. Встреча без письменного итога не снимает спор, а переносит его на неделю.