Питання на співбесіді QA Automation-інженера

Ті, що виконуються часто й дають стабільний результат: смоук і регресія критичних сценаріїв (вхід, оплата, оформлення замовлення), перевірки API, тести з великою кількістю даних.

Не варто автоматизувати одноразові перевірки, функції, що постійно змінюються, і те, що потребує людської оцінки: юзабіліті, візуальне враження. Автоматизація має окупатися — підтримка тесту не повинна коштувати більше, ніж ручна перевірка.

Найстабільніші — ті, що не залежать від верстки: спеціальні атрибути data-testid, ролі й доступні назви (getByRole('button', { name: 'Оформити замовлення' }) у Playwright), підписи полів.

Крихкі — довгі XPath за структурою (/div[3]/span[2]) і згенеровані CSS-класи, які змінюються після кожної збірки. Домовленість із розробниками про data-testid значно зменшує кількість зламаних тестів.

Фіксована пауза або занадто коротка (тест падає на повільному оточенні), або занадто довга (весь набір тестів виконується годинами).

Правильно — очікувати конкретну умову: елемент видимий, запит завершився, текст з'явився. Playwright робить автоматичні очікування для дій і перевірок, у Selenium використовують явні очікування (WebDriverWait).

Page Object — клас, який описує сторінку або компонент: локатори й дії (login(email, password)). Тести працюють з методами, а не з локаторами напряму.

Коли змінюється верстка, правку вносять в одному місці, а не в десятках тестів. Тести стають читабельнішими: loginPage.login(user) замість трьох рядків з локаторами. Важливо не перетворювати Page Object на «божественний клас» із перевірками й логікою тестів.

• Знайти причину, а не просто перезапускати: очікування, залежність від порядку тестів, спільні тестові дані, анімації, мережа, час і часові пояси;
• ізолювати тести: кожен створює власні дані і не залежить від інших;
• використовувати стабільні локатори й очікування умов;
• мокати нестабільні зовнішні сервіси;
• тимчасово виносити flaky-тести в карантин із задачею на виправлення.

Нестабільні тести шкодять більше, ніж їх відсутність: команда перестає довіряти результатам.

Найнадійніше — кожен тест створює потрібні дані сам через API або напряму в БД і прибирає їх після себе. Тоді тести можна запускати паралельно й у будь-якому порядку.

Для складних даних — фабрики й білдери (UserBuilder().withOrders(3).build()), унікальні значення (email із таймстемпом). Спільні «вічні» тестові акаунти — часта причина нестабільності, бо їх змінюють інші тести чи люди.

Playwright має автоматичні очікування, вбудовану ізоляцію через browser contexts, перехоплення мережевих запитів, трасування з відео й знімками кожного кроку, паралельний запуск «з коробки» та підтримку Chromium, Firefox і WebKit.

Selenium лишається стандартом для великих наявних наборів тестів, Selenium Grid і специфічних браузерів. Перехід має сенс, коли витрати на підтримку старих тестів високі — і його зазвичай роблять поступово.

Клієнт для API з методами для ендпоінтів, моделі для запитів і відповідей, валідація схеми відповіді (JSON Schema або за OpenAPI). Перевіряють статуси, структуру, бізнес-правила, негативні сценарії й права доступу.

API-тести швидкі й стабільні, тому на них зручно покласти основну частину регресії, а UI-тестами лишити кілька наскрізних сценаріїв. Підготовку даних для UI-тестів теж роблять через API — це швидше, ніж клікати форми.

• Шари: тести → кроки/бізнес-дії → Page Objects і API-клієнти → драйвер;
• конфігурація оточень без змін коду, секрети — зі змінних оточення;
• фабрики тестових даних і автоматичне прибирання;
• зрозумілі звіти (Allure, HTML-звіт Playwright) з логами, скріншотами й трасуванням;
• лінтер, код-рев'ю тестового коду як продуктового;
• документація для нових членів команди.

Тестовий код — такий самий код, і без інженерних практик він швидко стає некерованим.

• Паралельний запуск і шардинг між кількома машинами в CI;
• переносити перевірки з UI на рівень API та юніт-тестів;
• підготовка даних через API, повторне використання стану автентифікації;
• запуск лише релевантних тестів для зміни (за тегами чи змінними модулями), а повного набору — за розкладом;
• видалити дублюючі й застарілі тести.

Мета — щоб розробник отримував результат за хвилини, інакше тести ігнорують.

AI-асистенти пришвидшують написання тестів, Page Objects і тестових даних; Playwright уміє генерувати тести за записом дій і пропонувати локатори; з'являються агенти, що досліджують застосунок і пропонують сценарії, та «самовідновлювані» локатори.

Ризики: тести, що перевіряють не те, надмірні або дубльовані перевірки, приховування реальних дефектів «самовідновленням». Тому згенерований тест проходить рев'ю, а метрика — не кількість тестів, а знайдені дефекти й довіра команди до результатів.

Різні рівні в різних точках: юніт- і API-тести на кожен pull request як обов'язкова перевірка перед злиттям, смоук після деплою на тестове оточення, повна регресія — щоночі або перед релізом.

Тести запускаються в Docker з однаковим оточенням, результати й звіти доступні в PR. Важливо домовитися з командою, хто й як швидко виправляє впалі тести, — інакше червоний CI стає нормою.