На собеседовании QA Automation проверяют знание фреймворков, паттернов автоматизации и — прежде всего — умение писать тесты, которые остаются зелёными не по случайности. Ниже — частые вопросы с эталонными ответами. Senior: архитектуру, трейд-оффы, менторство и принятие решений.
В его терминах: стоимость релиза, время от коммита до уверенности, дефекты, дошедшие до клиента. Набор, стоивший двух инженеров на месяц и экономящий десять ручных часов на релиз, окупается при недельном цикле и не окупается при квартальном — арифметика у каждой команды своя, и её надо показать, а не заявить. Честная часть ответа — назвать, что автоматизировано не будет и почему.
Сначала измерить, ничего не трогая: какие падают чаще, какие идут дольше, какие ни разу не поймали настоящий дефект. Обычно на боль приходится небольшое их число. Нестабильные вынести в карантин, чтобы сборка позеленела и команда снова начала ей доверять, затем чинить или удалять. Удаление — реальный вариант: тест, которому не верят, имеет отрицательную ценность, потому что стоит внимания и не даёт ничего.
Помогает, когда сценарии действительно читают и пишут неинженеры, что бывает редко и требует владельца языка. Делает хуже, когда команда пишет Gherkin сама для себя: получается английская прослойка над кодом, которую снаружи никто не читает, плюс уровень step definitions, превращающий правку в две строки в поиск. Если продакт ни разу не открыл feature-файл, их стоит убрать.
Взвешивать дорогое к изменению: язык, на котором команда уже пишет, как инструмент работает с ожиданиями, запускается ли он в CI без дисплея, насколько жив проект — частота релизов, возраст открытых issue. Бенчмарки скорости весят меньше всего, потому что время прогона определяется вашим приложением, а не драйвером. Стоит спросить, что будет, когда инструмент забросят.
Падение, которое говорит, что сломалось, а не что проверка вернула false: шаг, скриншот, сетевой лог, разница между ожидаемым и фактическим. Группировка по предполагаемой причине, а не по файлам, важнее оформления. Настоящая мера — может ли инженер за тридцать секунд решить, его это падение или нет; всё, что дольше, пролистывают.
Сначала пропущенные дефекты — баги, дошедшие до прода в области, покрытой тестами, потому что именно это набор и должен предотвращать. Затем доля нестабильных и время от коммита до сигнала, которому можно верить. Процент покрытия — метрика, которой стоит не доверять: его легко поднять, ничего осмысленного не проверив, и команда, которой велели его поднять, так и сделает.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Senior QA Automation →