Питання на співбесіді QA-інженера (тестувальника)

Верифікація відповідає на питання «чи правильно ми робимо продукт» — чи відповідає він вимогам і специфікації. Валідація — «чи робимо ми правильний продукт» — чи вирішує він реальну задачу користувача.

Приклад: форма реєстрації працює точно за ТЗ (верифікація пройдена), але користувачі не можуть знайти кнопку «Зареєструватися» (валідація не пройдена).

• Короткий зрозумілий заголовок: що, де і за яких умов;
• кроки відтворення;
• фактичний і очікуваний результат;
• оточення: браузер, ОС, версія застосунку, тестовий акаунт;
• серйозність (severity) і пріоритет;
• докази: скріншот, відео, логи, запит із DevTools.

Добрий баг-репорт розробник може відтворити без додаткових питань.

Severity — наскільки серйозний вплив дефекту на систему: від тривіального до блокуючого. Priority — наскільки терміново його треба виправити з погляду бізнесу.

Приклади: помилка в назві компанії на головній — низька severity, високий priority. Падіння застосунку в рідкісному сценарії в адмінці, яким користуються раз на рік, — висока severity, але priority може бути низьким.

• Смоук-тестування — швидка перевірка, що основні функції працюють і збірку взагалі можна тестувати;
• ретест — повторна перевірка конкретного виправленого бага;
• регресійне тестування — перевірка, що нові зміни не зламали те, що працювало раніше.

Регресію найчастіше автоматизують, бо її повторюють перед кожним релізом.

Поле «вік» приймає значення від 18 до 65. Класи еквівалентності: менше 18 (невалідний), 18–65 (валідний), більше 65 (невалідний), а також нечислові значення й порожнє поле.

Граничні значення: 17, 18, 19 і 64, 65, 66. Саме на межах найчастіше помиляються розробники (< замість <=). Так замість сотні перевірок отримуємо десяток, які покривають основні ризики.

• Позитивні сценарії: правильні статуси, структура й типи полів у відповіді;
• негативні: невалідні дані, відсутні обов'язкові поля, неправильні типи, дуже довгі значення;
• автентифікація й права: без токена, з простроченим токеном, чужий ресурс (чи не можна отримати чуже замовлення, змінивши ID);
• граничні випадки пагінації й фільтрів;
• ідемпотентність, швидкодія, коректні повідомлення про помилки.

Інструменти: Postman або Bruno, перевірка за документацією OpenAPI, Charles чи DevTools для перехоплення запитів.

Тестування на основі ризиків: визначити, що найважливіше для бізнесу і де найімовірніші помилки, — оплата, реєстрація, нові зміни, місця з частими багами в минулому.

Далі — смоук критичних сценаріїв, детальне тестування нового функціоналу, вибіркова регресія суміжних модулів. Важливо прозоро повідомити команді, що не перевірено і які ризики лишаються, щоб рішення про реліз ухвалювали свідомо.

• Network — переглянути запити й відповіді, статуси, час завантаження, повторити запит, емулювати повільну мережу;
• Console — помилки JavaScript, які не видно в інтерфейсі;
• Elements — перевірити верстку, атрибути, приховані елементи;
• Application — cookies, localStorage, сесії;
• режим пристрою — адаптивність під мобільні екрани.

До баг-репорту корисно додавати HAR-файл або скріншот запиту з Network.

Спочатку зрозуміти продукт, ризики та поточні проблеми: де найбільше багів у продакшні, скільки часу займає регресія. Далі:

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

Якість — відповідальність усієї команди, а QA допомагає її організувати.

AI допомагає генерувати чернетки тест-кейсів за вимогами, тестові дані, SQL-запити, скрипти автотестів, аналізувати логи й групувати схожі баги. Також з'явилася нова задача — тестування самих AI-функцій: недетерміновані відповіді, галюцинації, prompt injection, упередженість.

Але AI не замінює розуміння продукту: згенеровані кейси часто поверхові й пропускають бізнес-контекст. Сильна відповідь — з прикладом, де AI заощадив час і як ви перевіряли його результат.

Перебрати всі комбінації неможливо: 5 параметрів по 4 значення — це 1024 варіанти. Підходи:

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

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

Висновки перетворюють на конкретні дії: додати автотест, змінити чек-лист регресії, покращити вимоги, додати моніторинг. Корисно відстежувати тенденції: які модулі й типи дефектів повторюються, — і зміщувати фокус тестування туди.