Как происходит взаимодействие с автоматизатором в команде

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

Как у вас устроена граница между ручным тестированием и автоматизацией: кто решает, что автоматизировать, и кто разбирает упавшие автотесты. Интервьюер хочет услышать общий процесс, а не «я отдаю кейсы, он пишет». Частый уточняющий вопрос: по каким признакам вы отдаёте проверку в автоматизацию.

Как отвечать

Рассказывайте на своём проекте и со своими цифрами: сколько кейсов в регрессе, какая доля автоматизирована, сколько длится прогон. Каркас такой:

• отбор: автоматизируют стабильную функциональность, регресс, частые и рискованные сценарии, проверки с большим набором данных. Фичу, у которой ещё меняется интерфейс, оставляют ручной;
• общий источник кейсов: тест-кейсы живут в TMS (TestRail, Qase, Allure TestOps), у каждого есть статус автоматизации и ссылка на автотест. Так вы не гоняете вручную то, что уже проверяет CI;
• качество кейса: шаги, данные, предусловия и ожидаемый результат написаны так, чтобы их можно было однозначно превратить в проверку;
• уровень проверки: вместе решаете, где тест дешевле. Многое из того, что вы проверяете через интерфейс, быстрее и стабильнее проверить на уровне API;
• разбор падений: договорённость, кто утром смотрит красный прогон. Вы определяете, баг это или флаки, автоматизатор чинит тест или окружение;
• ревью: вы читаете автотест и смотрите, проверяет ли он то, что обещает кейс, а не только то, что страница открылась.

Если выделенного автоматизатора в команде не было, так и скажите. Расскажите, как делили эту работу с разработчиками, или опишите, как построили бы процесс.

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

Описывают передачу через стену: написал кейсы, отдал, дальше не моё. Интервьюер слышит, что покрытие никто не сверяет.

Предлагают автоматизировать всё подряд. Автотесты на нестабильный интерфейс ломаются чаще, чем находят баги, и команда перестаёт им доверять.

Перезапускают упавший тест, пока он не позеленеет. Нестабильный тест заводят задачей и чинят, иначе настоящее падение утонет среди ложных.