Співбесіда QA: питання та тренування з ШІ

Чим відрізняються severity і priority?

Що має бути в сильній відповіді:Severity показує, наскільки сильно баг впливає на систему, а priority — як терміново його треба виправити з погляду бізнесу. Вони виставляються незалежно: помилка в назві компанії на головній — низька severity, але високий priority, а падіння рідко використовуваного звіту в адмінці може мати високу severity і нижчий priority. Варто додати, що severity зазвичай ставить QA, а остаточне слово щодо priority часто за PM або лідом.

Яка різниця між smoke, sanity і regression тестуванням?

Що має бути в сильній відповіді:Smoke — швидка поверхнева перевірка, чи новий білд узагалі придатний до тестування: застосунок запускається, логін працює, ключові сторінки відкриваються. Sanity — вузька перевірка, що конкретний фікс чи зміна працює як треба. Regression перевіряє, що старий функціонал не зламався після змін, і саме його найчастіше автоматизують, бо він повторюється кожного релізу.

Як застосувати аналіз граничних значень до поля, яке приймає вік від 18 до 60?

Що має бути в сильній відповіді:Спочатку ділимо вхідні дані на класи еквівалентності: менше 18, від 18 до 60, більше 60, плюс невалідні значення на кшталт літер або порожнього поля. Далі тестуємо межі, де баги трапляються найчастіше: 17, 18, 60 і 61, а для трьохточкового варіанта ще 19 і 59. Так кількома test cases отримуємо гарне покриття замість перевірки кожного числа.

Що має містити якісний bug report?

Що має бути в сильній відповіді:Короткий і конкретний заголовок, чіткі кроки відтворення, очікуваний і фактичний результат та оточення: версія білда, браузер або девайс, ОС, тестові дані. Додайте докази — скриншот, відео, логи чи запит до API, який падає, — і виставте severity. Простий критерій: інша людина має відтворити баг, нічого у вас не перепитуючи.

Чим верифікація відрізняється від валідації?

Що має бути в сильній відповіді:Верифікація відповідає на питання «чи правильно ми робимо продукт?»: перевіряємо відповідність вимогам і специфікаціям, наприклад через рев’ю вимог, дизайну й коду. Валідація — «чи той продукт ми робимо?»: перевіряємо, що результат справді закриває потреби користувача, зазвичай тестуючи робоче ПЗ. Коротко: верифікація — проти специфікації, валідація — проти потреб користувача.

Які HTTP-методи ідемпотентні і чому це важливо для тестування API?

Що має бути в сильній відповіді:GET, PUT, DELETE, HEAD і OPTIONS ідемпотентні: повторний однаковий запит залишає сервер у тому самому стані. POST не ідемпотентний, PATCH — не гарантовано. На практиці QA надсилає однаковий PUT чи DELETE двічі й перевіряє, що нічого зайвого не сталося, а для POST перевіряє, як API обробляє дублікати, наприклад через idempotency key або унікальне обмеження в базі.

Чим відрізняються статус-коди 401 і 403 і як ви тестуєте авторизацію?

Що має бути в сильній відповіді:401 Unauthorized означає, що запит не автентифікований: токена немає, він прострочений або зламаний. 403 Forbidden — користувач автентифікований, але не має прав на цей ресурс. Для перевірки викликаємо кожен ендпоінт без токена, з простроченим токеном і з токеном користувача з іншою роллю, а також перевіряємо, що, підмінивши ID, не можна прочитати чи змінити чужі дані.

Яка різниця між INNER JOIN і LEFT JOIN і коли це потрібно QA?

Що має бути в сильній відповіді:INNER JOIN повертає лише рядки, що мають збіг в обох таблицях, LEFT JOIN — усі рядки лівої таблиці, а там, де збігу праворуч немає, підставляє NULL. QA часто використовує LEFT JOIN з умовою WHERE права_таблиця.id IS NULL, щоб знайти «осиротілі» або відсутні дані: користувачів без профілю чи замовлення без оплати. Це типовий спосіб перевірити цілісність даних після міграції або змін на бекенді.

Через що виникають flaky-тести і як з ними боротися?

Що має бути в сильній відповіді:Типові причини: проблеми з таймінгами й жорсткі sleep, спільні або «брудні» тестові дані, залежність від порядку тестів, нестабільне оточення чи сторонні сервіси, крихкі локатори. Лікувати треба причину: явні очікування або auto-waiting, ізольовані дані для кожного тесту, моки для нестабільних залежностей, стабільні локатори на кшталт data-testid. Retries у CI зменшують шум, але flaky-тести треба відстежувати й виносити в карантин, а не перезапускати мовчки.

Що таке Page Object Model і які в нього мінуси?

Що має бути в сильній відповіді:Page Object Model виносить локатори й дії зі сторінкою в окремі класи, тож тести читаються як бізнес-кроки, а зміна UI виправляється в одному місці, а не в кожному тесті. Мінуси: роздуті «god»-об’єкти, перевірки, що протікають у page-класи, і зайві шари для простих сторінок. Сильна відповідь згадує, що assertions мають лишатися в тестах, повторювані компоненти варто виносити окремо, а в Playwright і Cypress часто використовують легші підходи — fixtures або custom commands.

Як ви побудуєте тест-стратегію для нового продукту з нуля?

Що має бути в сильній відповіді:Почати з ризиків і бізнес-пріоритетів: які флоу приносять гроші або найбільше зашкодять користувачам, якщо зламаються. Далі визначити рівні тестування й баланс між unit, API та UI-тестами, оточення й тестові дані, критерії входу та виходу, а також що запускається в CI на кожну зміну, а що — перед релізом. Варто пояснити, як ви узгодите це з розробниками й продактом і як міряти результат, наприклад за багами з продакшну та часом зворотного зв’язку від тестів.

Як ви вирішуєте, що автоматизувати, а що залишити ручним?

Що має бути в сильній відповіді:Автоматизуємо те, що часто повторюється, стабільне, критичне для бізнесу й має чіткий очікуваний результат: regression, smoke, контракти API, сценарії з великою кількістю даних. Ручними залишаються exploratory, юзабіліті, разові перевірки та фічі, чий UI змінюється щоспринту. І ще — опускати перевірки нижче по піраміді: якщо щось можна перевірити unit- або API-тестом, не варто покривати це повільним end-to-end тестом через UI.

Ваш end-to-end набір іде в CI 90 хвилин. Як його пришвидшити?

Що має бути в сильній відповіді:Спершу виміряти: знайти найповільніші й найчастіше червоні тести та прибрати дублікати того, що вже покрито на рівні API чи unit. Потім запускати тести паралельно з ізольованими даними, готувати стан через API або сідинг бази замість кліків в UI, перевикористовувати стан авторизації. І нарешті розділити пайплайн: швидкий smoke-набір на кожен pull request, повна регресія — щоночі або перед релізом.

Як ви тестуватимете REST API, від якого залежать інші команди?

Що має бути в сильній відповіді:Покрити функціональні та негативні кейси, валідацію, авторизацію за ролями й формат помилок. Контракт захистити перевіркою схеми або consumer-driven contract тестами, наприклад Pact, щоб ламаюча зміна падала в CI ще до того, як дійде до інших команд. Додати перевірки зворотної сумісності й версіонування, а також базові performance-тести ключових ендпоінтів.

Які QA-метрики ви вважаєте корисними, а яких уникаєте?

Що має бути в сильній відповіді:Корисні ті, що показують якість продукту і швидкість команди: баги, які дійшли до продакшну, час від коміту до результату тестів, частка flaky-тестів і покриття критичних користувацьких сценаріїв. Сирі числа на кшталт кількості test cases чи знайдених багів на тестувальника легко «накрутити», і про якість вони говорять мало. Сильна відповідь пояснює, що метрики мають допомагати ухвалювати рішення, наприклад яку зону докрити тестами, а не ранжувати людей.