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