Питання на співбесіді QA Engineer: 40 питань і відповідей для Junior-тестувальника
Коротка відповідь: на співбесіді Junior QA перевіряють чотири речі — чи знаєте ви теорію тестування в термінах ISTQB, чи вмієте застосовувати техніки тест-дизайну на живому прикладі, чи можете зрозуміло оформити баг-репорт і чи орієнтуєтеся в технічній базі: HTTP, API, SQL, DevTools. У цій статті 40 питань із короткими відповідями, згруповані за сімома темами, п'ять практичних завдань із розв'язками, типові помилки кандидатів і план підготовки на два тижні.
Я чотири роки працювала QA Engineer, а тепер як Project Delivery Manager відповідаю за delivery проєктів і бачу тестування з іншого боку: які навички тестувальника справді допомагають команді випустити продукт. Питання нижче я добирала з цього погляду та з урахуванням роботи над курсами з QA. Майже в кожній відповіді важливіше не визначення, а приклад, яким ви його підтверджуєте.
Визначення подано за змістом глосарія ISTQB і програми Certified Tester Foundation Level v4.0. SQL-запити виконано в SQLite 3.51, приклад на JavaScript — у Node.js 22, автотест — у Playwright 1.59; вивід у статті справжній. Добірка питань — авторський вибір на основі досвіду роботи в тестуванні, а не статистика: у конкретній компанії перелік може відрізнятися.
Як проходить співбесіда на QA Engineer?
Зазвичай співбесіда на Junior QA складається з чотирьох етапів: скринінг із рекрутером, технічне інтерв'ю, практичне завдання і фінальна зустріч із керівником або командою. Порядок і кількість етапів залежать від компанії: у невеликих командах усе може вміститися в одну розмову.
| Етап | Що перевіряють | Як готуватися |
|---|---|---|
| Скринінг із рекрутером | Мотивацію, англійську, очікування щодо зарплати та формату роботи, загальне розуміння професії | Підготуйте розповідь про себе на дві хвилини, відповідь «чому тестування» і вилку очікувань |
| Технічне інтерв'ю | Теорію, тест-дизайн, документацію, HTTP та API, SQL, іноді основи автоматизації | Повторіть питання з цієї статті й до кожного визначення доберіть власний приклад |
| Практичне завдання | Уміння протестувати об'єкт або вимогу, написати тест-кейси, оформити баг-репорт, скласти SQL-запит | Розв'яжіть завдання з розділу із практикою письмово і з таймером |
| Фінальна зустріч | Як ви спілкуєтеся, реагуєте на спірні ситуації, чи вписуєтеся в команду | Пригадайте ситуації з навчання або попередньої роботи: конфлікт, помилка, стислі терміни |
Якщо ви лише придивляєтеся до професії, почніть з огляду що таке QA і статті QA Engineer в епоху AI. Медіанні зарплати за рівнями зібрано на сторінці зарплати QA Engineer.
Які теми питають і на якому рівні?
Junior питають передусім теорію, тест-дизайн, документацію і технічну базу; з Middle глибше обговорюють процеси, планування, API та автоматизацію. Таблиця показує, що саме перевіряють у кожній темі. Позначка рівня — орієнтир авторки, а не стандарт.
| Тема | Що перевіряють | Рівень |
|---|---|---|
| Теорія тестування | Терміни ISTQB, принципи, рівні й типи тестування | Junior |
| Техніки тест-дизайну | Уміння застосувати техніку до конкретного поля або вимоги | Junior |
| Тестова документація | Тест-кейс, чек-лист, баг-репорт, severity і priority | Junior |
| Тест-план, оцінювання, критерії завершення | Уміння спланувати тестування і пояснити, що не буде перевірено | Middle |
| Процеси | Життєвий цикл розробки, роль тестувальника у Scrum-команді | Junior / Middle |
| Веб і клієнт-сервер | HTTP-методи, коди відповідей, cookies, DevTools | Junior |
| Тестування API | REST, Postman, перевірки відповіді, негативні сценарії | Junior / Middle |
| SQL | SELECT, JOIN, GROUP BY | Junior |
| Мобільне тестування | Специфіка мобільних застосунків, пристрої та емулятори | Junior / Middle |
| Автоматизація | Що автоматизувати, піраміда тестування, інструменти на рівні концепцій | Junior — концепції, Middle — практика |
| AI-інструменти | Де асистент допомагає і як ви перевіряєте його результат | Junior / Middle |
Теорія тестування
Визначення в цьому блоці відповідають глосарію ISTQB. Вчити їх дослівно не потрібно, але зміст має збігатися: інтерв'юер, як правило, звіряє відповідь саме з ним.
Чим відрізняються QA, QC і тестування?
QA (забезпечення якості) — це робота над процесом, щоб дефекти не з'являлися; QC (контроль якості) — перевірка готового продукту; тестування — одна з форм контролю якості. У програмі ISTQB це сформульовано так: QA — процесно-орієнтований, запобіжний підхід, QC — продукт-орієнтований, коригувальний.
Приклад: домовитися, що кожна вимога проходить рев'ю до початку розробки, — це QA. Перевірити зібрану версію і знайти, що кнопка оплати не працює, — QC, і конкретно тестування. Посада при цьому зазвичай називається QA Engineer, хоча більша частина щоденної роботи — тестування. Докладніше — у глосарії: тестування програмного забезпечення.
У чому різниця між верифікацією і валідацією?
Верифікація відповідає на питання «чи відповідає продукт специфікації?», валідація — «чи відповідає він потребам користувача і замовника?». Коротка формула: верифікація — «робимо продукт правильно», валідація — «робимо правильний продукт».
Приклад: у вимозі написано, що пароль містить щонайменше 8 символів. Ви перевірили, що 7 символів не приймаються, — це верифікація. Користувачі на приймальному тестуванні не можуть знайти кнопку «Показати пароль» і кидають реєстрацію, хоча все реалізовано за специфікацією, — це провал валідації.
Які принципи тестування ви знаєте?
У програмі ISTQB Foundation Level сім принципів. Перелічіть їх і до одного-двох наведіть приклад.
- Тестування показує наявність дефектів, а не їхню відсутність.
- Вичерпне тестування неможливе.
- Раннє тестування заощаджує час і гроші.
- Дефекти скупчуються: більшість із них зазвичай міститься в невеликій кількості модулів.
- Тести зношуються: ті самі перевірки з часом перестають знаходити нові дефекти (у попередніх версіях програми це називали «парадоксом пестициду»).
- Тестування залежить від контексту.
- Хибне уявлення про відсутність дефектів: продукт без знайдених дефектів може все одно не розв'язувати задачу користувача.
Що хочуть почути: не перелік напам'ять, а висновок. Наприклад: оскільки вичерпне тестування неможливе, набір перевірок обирають за допомогою технік тест-дизайну та оцінки ризиків.
Які рівні тестування існують?
Програма ISTQB v4.0 виділяє п'ять рівнів: компонентне (модульне), компонентне інтеграційне, системне, системне інтеграційне і приймальне тестування. Рівні різняться об'єктом перевірки і тим, хто зазвичай її виконує.
| Рівень | Що перевіряють | Хто зазвичай виконує |
|---|---|---|
| Компонентне | Окрему функцію, клас або модуль в ізоляції | Розробники |
| Компонентне інтеграційне | Взаємодію компонентів між собою | Розробники |
| Системне | Поведінку всієї системи загалом, зокрема нефункціональні характеристики | Команда тестування |
| Системне інтеграційне | Взаємодію системи із зовнішніми системами та сервісами | Команда тестування |
| Приймальне | Готовність системи до використання і відповідність потребам бізнесу | Користувачі, замовник, власник продукту |
У глосарії розібрано модульне, інтеграційне та наскрізне (E2E) тестування.
Які типи тестування ви знаєте?
Типи тестування групують перевірки за метою: функціональне тестування перевіряє, що система робить, нефункціональне — наскільки добре вона це робить. До нефункціональних характеристик належать продуктивність, безпека, зручність використання, сумісність, надійність.
Окрема вісь — на чому ґрунтуються тести. Тестування методом чорної скриньки будується на специфікації і не потребує знання коду, методом білої скриньки — на внутрішній структурі коду. Третя вісь — статичне тестування (рев'ю вимог і коду без запуску програми) і динамічне (із запуском).
Типова помилка: плутати рівні й типи. «Системне» — це рівень, «функціональне» — тип; функціональні тести виконують на будь-якому рівні.
Чим відрізняються smoke, sanity, повторне і регресійне тестування?
Smoke-тест перевіряє, що основна функціональність збірки працює і її є сенс тестувати далі; повторне (підтверджувальне) тестування перевіряє, що конкретний дефект виправлено; регресійне — що зміни не зламали те, що працювало раніше.
Із sanity обережніше: у глосарії ISTQB це синонім smoke-тесту. У розмовній практиці команд sanity часто називають швидку вузьку перевірку однієї зміненої ділянки після невеликої правки. На співбесіді назвіть обидва варіанти й уточніть, як термін використовують у цій команді.
Приклад: вийшла збірка з виправленням розрахунку знижки. Smoke — застосунок відкривається, можна увійти й оформити замовлення. Повторний тест — знижка тепер рахується правильно у сценарії з баг-репорту. Регресія — кошик, оплата та історія замовлень працюють як раніше.
Що таке помилка, дефект і відмова?
Помилка — це дія людини, яка призводить до неправильного результату; дефект — вада в коді або документі, що з'явилася через помилку; відмова — подія, коли система під час роботи поводиться не так, як має. Ланцюжок виглядає так: людина помилилася, у продукті з'явився дефект, під час виконання дефектного коду може статися відмова.
Не кожен дефект призводить до відмови: дефектний код може жодного разу не виконатися. А слово «баг» у командах уживають і для дефекту, і для відмови, і це нормально, поки ви розумієте різницю.
Техніки тест-дизайну
Це головний практичний блок. У кожному питанні інтерв'юер чекає, що ви візьмете поле або вимогу і покажете техніку на ньому. Перші приклади побудовано на одній вимозі: поле «Вік» приймає цілі числа від 18 до 65 включно.
Що таке техніки тест-дизайну і навіщо вони потрібні?
Техніки тест-дизайну — це способи обрати з нескінченної кількості можливих перевірок невеликий набір, який з найбільшою ймовірністю знайде дефекти. Вони потрібні, бо вичерпне тестування неможливе.
ISTQB поділяє техніки на три групи: чорної скриньки (класи еквівалентності, аналіз граничних значень, таблиці рішень, переходи станів), білої скриньки (покриття операторів і гілок) та засновані на досвіді (передбачення помилок, дослідницьке тестування, тестування за чек-листами).
Що таке розбиття на класи еквівалентності?
Це техніка, за якої вхідні дані ділять на групи, у межах яких система має поводитися однаково, і з кожної групи беруть по одному значенню. Якщо одне значення класу оброблено правильно, припускають, що й решту буде оброблено так само.
Для поля «Вік» виходить три класи на числовій осі: менше за 18 (неприпустимий), від 18 до 65 (припустимий), більше за 65 (неприпустимий). Достатньо трьох перевірок, наприклад 10, 40 і 80. Окремі неприпустимі класи — взагалі не числа: порожнє поле, текст, дробове число, від'ємне число, пробіли.
Що хочуть почути: що ви назвали і припустимі, і неприпустимі класи і що неприпустимі значення перевіряють по одному, щоб одна помилка не маскувала іншу.
Що таке аналіз граничних значень?
Це техніка, яка перевіряє значення на межах класів еквівалентності, бо дефекти найчастіше виникають саме там, наприклад через знак «більше» замість «більше або дорівнює». Вона застосовна лише до впорядкованих даних: чисел, дат, довжини рядка.
У двозначному варіанті беруть межу і найближче значення із сусіднього класу: 17, 18, 65, 66. У тризначному — межу та обох її сусідів: 17, 18, 19 і 64, 65, 66. Нижче ті самі шість значень у вигляді невеликого автоматичного тесту на вбудованому тест-ранері Node.js.
const test = require('node:test');
const assert = require('node:assert/strict');
// Requirement: the "Age" field accepts whole numbers from 18 to 65 inclusive.
function isValidAge(value) {
return Number.isInteger(value) && value >= 18 && value <= 65;
}
const cases = [
[17, false], // just below the lower boundary
[18, true], // lower boundary
[19, true], // just above the lower boundary
[64, true], // just below the upper boundary
[65, true], // upper boundary
[66, false], // just above the upper boundary
];
for (const [age, expected] of cases) {
test(`age ${age} -> ${expected}`, () => {
assert.equal(isValidAge(age), expected);
});
}
Запуск командою node --test age.test.js завершується зведенням:
# tests 6
# pass 6
# fail 0
Що таке таблиця рішень?
Таблиця рішень — це техніка для логіки, де результат залежить від комбінації кількох умов: у стовпцях перелічують усі комбінації умов, у рядках — умови та очікувані дії. Кожен стовпець стає тест-кейсом.
Приклад вимоги: постійний клієнт отримує знижку 10 %, замовлення від 1000 грн дає знижку 5 %, знижки підсумовуються. Дві умови дають чотири правила.
| Правило 1 | Правило 2 | Правило 3 | Правило 4 | |
|---|---|---|---|---|
| Постійний клієнт | Так | Так | Ні | Ні |
| Сума замовлення від 1000 грн | Так | Ні | Так | Ні |
| Знижка | 15 % | 10 % | 5 % | 0 % |
За n умов із відповідями «так/ні» повна таблиця містить 2n стовпців, тому техніка добре показує пропущені у вимогах комбінації.
Що таке тестування переходів станів?
Цю техніку застосовують, коли поведінка системи залежить від її поточного стану: описують стани, події та припустимі переходи, а потім перевіряють і припустимі, і неприпустимі переходи.
Приклад — замовлення в інтернет-магазині зі статусами «Нове», «Оплачене», «Відправлене», «Доставлене», «Скасоване».
| Поточний стан | Подія | Наступний стан |
|---|---|---|
| Нове | Оплата пройшла | Оплачене |
| Нове | Скасування користувачем | Скасоване |
| Оплачене | Передано в доставку | Відправлене |
| Оплачене | Скасування користувачем | Скасоване (з поверненням коштів) |
| Відправлене | Отримано покупцем | Доставлене |
| Доставлене | Скасування користувачем | Перехід неприпустимий: статус не змінюється, показано повідомлення |
Що хочуть почути: що ви перевіряєте не лише «щасливий шлях», а й заборонені переходи — оплатити скасоване замовлення, скасувати доставлене.
Що таке попарне тестування (pairwise)?
Pairwise — це комбінаторна техніка, за якої набір тестів покриває кожну пару значень будь-яких двох параметрів щонайменше один раз, замість перебору всіх можливих комбінацій. Вона спирається на спостереження, що дефекти частіше спричиняє одне значення або поєднання двох параметрів, ніж трьох і більше.
Приклад: браузер (Chrome, Firefox, Edge), операційна система (Windows, macOS), мова інтерфейсу (UA, EN). Повний перебір — 3 × 2 × 2 = 12 комбінацій. Усі пари покриваються шістьма.
| № | Браузер | ОС | Мова |
|---|---|---|---|
| 1 | Chrome | Windows | UA |
| 2 | Chrome | macOS | EN |
| 3 | Firefox | Windows | EN |
| 4 | Firefox | macOS | UA |
| 5 | Edge | Windows | UA |
| 6 | Edge | macOS | EN |
На реальних проєктах такі набори будують інструментом, а не вручну. До програми ISTQB Foundation Level pairwise не входить, але питають про нього часто, тому знати ідею корисно.
Що таке дослідницьке тестування і передбачення помилок?
Це техніки, засновані на досвіді. У дослідницькому тестуванні тести проєктують, виконують і оцінюють одночасно, під час вивчення продукту; передбачення помилок — це здогад, де дефекти ймовірні, на основі досвіду і знання типових проблем.
Дослідницьке тестування не означає «клацати навмання»: зазвичай його проводять сесіями з метою та обмеженням у часі, а результати записують. Приклад передбачення помилок для будь-якого текстового поля: пробіли на початку і в кінці, дуже довгий рядок, емодзі, вставлення з буфера обміну, подвійний клік по кнопці надсилання.
Тестова документація і баг-репорти
Чим тест-кейс відрізняється від чек-листа?
Тест-кейс — це докладний опис однієї перевірки: передумови, вхідні дані, кроки, очікуваний результат і постумови. Чек-лист — перелік того, що потрібно перевірити, без детальних кроків.
Тест-кейси потрібні, коли перевірку має однаково виконати будь-яка людина, коли сценарій складний або його планують автоматизувати. Чек-лист швидше писати й підтримувати, він пасує досвідченій команді та продукту, що часто змінюється. Ціна чек-листа — результат сильніше залежить від того, хто його проходить.
Ознаки доброго тест-кейсу: він перевіряє одну річ, не залежить від інших кейсів, а його очікуваний результат конкретний — «показано повідомлення „Неправильний email або пароль“», а не «система працює коректно».
Що входить до тест-плану?
Тест-план описує цілі, обсяг, підхід, ресурси та розклад тестування. На Junior достатньо назвати основні розділи; складати план зазвичай просять на рівні Middle.
- Що тестуємо і що залишається поза межами.
- Підхід: рівні й типи тестування, техніки, частка автоматизації.
- Критерії входу і виходу: коли починаємо і коли вважаємо роботу завершеною.
- Середовища, тестові дані, інструменти.
- Ролі, терміни та оцінка трудовитрат.
- Ризики і те, як із ними працюємо.
- Звітність: які метрики збираємо і кому повідомляємо.
Як оформити баг-репорт?
Добрий баг-репорт дає розробникові змогу відтворити проблему з першого разу, не ставлячи запитань. Обов'язкові частини: заголовок, середовище, кроки відтворення, фактичний і очікуваний результат, серйозність, вкладення.
| Поле | Приклад заповнення |
|---|---|
| Заголовок | Кошик: промокод SALE10 застосовується повторно після оновлення сторінки |
| Середовище | Тестовий стенд, збірка 2.14.0, Chrome останньої версії, Windows 11 |
| Передумови | Користувач авторизований, у кошику один товар на 1000 грн |
| Кроки | 1. Відкрити кошик. 2. Ввести промокод SALE10 і натиснути «Застосувати». 3. Оновити сторінку. 4. Знову ввести SALE10 і натиснути «Застосувати» |
| Фактичний результат | Знижку застосовано двічі, сума до сплати — 800 грн |
| Очікуваний результат | Показано повідомлення «Промокод уже застосовано», сума до сплати — 900 грн |
| Severity / Priority | Critical / High |
| Вкладення | Відео відтворення, відповідь сервера на запит застосування промокоду з вкладки Network |
Заголовок зручно будувати за схемою «де — що — за яких умов». Типові помилки: заголовок «Не працює кошик», кілька дефектів в одному репорті, оцінні слова замість фактів, відсутність очікуваного результату.
Чим severity відрізняється від priority?
Severity (серйозність) показує, наскільки сильно дефект впливає на роботу системи; priority (пріоритет) — наскільки терміново його потрібно виправити з погляду бізнесу. Серйозність зазвичай оцінює тестувальник, пріоритет — власник продукту або менеджер.
| Поєднання | Приклад |
|---|---|
| Висока серйозність, високий пріоритет | Не проходить оплата в усіх користувачів |
| Висока серйозність, низький пріоритет | Застосунок падає під час експорту звіту у формат, яким користуються одиниці і для якого є обхідний шлях |
| Низька серйозність, високий пріоритет | Одруківка в назві компанії на головній сторінці напередодні рекламної кампанії |
| Низька серйозність, низький пріоритет | Зміщена на кілька пікселів іконка в розділі налаштувань, який рідко відвідують |
Який життєвий цикл у дефекту?
Типовий шлях: новий → призначений → у роботі → виправлений → на перевірці → закритий; якщо виправлення не підтвердилося, дефект перевідкривають. Назви статусів залежать від трекера і домовленостей команди.
Бічні гілки: відхилений (не дефект, дублікат, не відтворюється) і відкладений (виправлять в одній із наступних версій). Тестувальник бере участь у двох точках: створює репорт і після виправлення проводить повторне тестування, а потім перевіряє сусідню функціональність на регресію.
Що ви зробите, якщо розробник відповідає «це не баг» або «у мене не відтворюється»?
Спершу перевірю власний репорт, потім повернуся до вимог, а якщо вимоги не дають відповіді — винесу питання на того, хто ухвалює рішення про продукт. Сперечатися про думки марно, потрібні факти.
- Відтворюю ще раз на чистих даних, уточнюю середовище, збірку, обліковий запис, додаю відео й логи.
- Якщо не відтворюється в розробника — порівнюємо середовища й дані, за потреби показую на своїй машині.
- Якщо суперечка «баг чи фіча» — шукаю вимогу або макет. Якщо їх немає, це прогалина у вимогах: питання вирішує власник продукту або бізнес-аналітик.
- Фіксую рішення в задачі, щоб до нього не повертатися.
Що хочуть почути: що ви захищаєте якість продукту, а не власну правоту, і не закриваєте дефект мовчки.
Процеси: SDLC, STLC, Agile і Scrum
Що таке SDLC і STLC?
SDLC — життєвий цикл розробки програмного забезпечення: від збирання вимог до супроводу. STLC — життєвий цикл тестування, тобто послідовність активностей тестування всередині SDLC.
У термінах ISTQB процес тестування складається з планування, моніторингу та контролю, аналізу («що тестувати»), проєктування («як тестувати»), реалізації (підготовка тест-кейсів, даних і середовища), виконання і завершення. У послідовних моделях на кшталт Waterfall тестування — окрема фаза після розробки, і пізно знайдені дефекти обходяться дорого. В Agile ті самі активності повторюються в кожній короткій ітерації разом із розробкою, регресію проводять постійно, тому зростає роль автоматизації.
Що робить тестувальник у Scrum-команді?
Тестувальник бере участь у всьому циклі спринту: уточнює вимоги до початку розробки, проєктує і виконує тести під час спринту та допомагає команді вирішити, чи готовий інкремент.
Варто знати, що у Scrum Guide окремої ролі тестувальника немає: у Scrum-команді є Product Owner, Scrum Master і Developers, і тестувальник належить до Developers. За якість відповідає вся команда.
| Подія | Що робить тестувальник |
|---|---|
| Уточнення беклогу (refinement) | Ставить запитання до історій, знаходить суперечності, пропонує критерії приймання |
| Планування спринту | Оцінює обсяг тестування, називає ризики та залежності |
| Щоденна зустріч | Повідомляє, що перевірено, що блокує, які дефекти критичні |
| Упродовж спринту | Пише тест-кейси або чек-листи, тестує готові задачі, заводить дефекти, проводить регресію |
| Огляд спринту і ретроспектива | Допомагає показати результат, пропонує поліпшення процесу |
Коли потрібно починати тестування?
Якомога раніше — з моменту появи вимог, а не готової збірки. Це прямо випливає з принципу «раннє тестування заощаджує час і гроші»; такий підхід називають shift left.
Тестування вимог — це статичне тестування: ви перевіряєте їх на повноту, однозначність, несуперечливість і перевірюваність. Приклад запитання до вимоги «поле приймає вік від 18 до 65»: чи включено межі, що показати в разі помилки, чи можна ввести дробове число. Дефект, знайдений на цьому етапі, виправляють правкою тексту, а не коду.
Як зрозуміти, що тестування можна завершувати?
Тестування завершують, коли виконано заздалегідь узгоджені критерії виходу, а не коли «дефекти перестали знаходитися». В Agile-командах цю роль відіграє Definition of Done.
Типові критерії: заплановані тести виконано, вимоги покрито, критичних і блокувальних дефектів немає, решта дефектів відомі та прийняті власником продукту, регресію пройдено. Якщо час скінчився раніше, чесна відповідь — звіт про залишкові ризики: що не перевірено і чим це загрожує. Рішення про випуск ухвалює бізнес, тестувальник дає для нього інформацію.
Ті самі теми — з викладачем і практикою
Курс QA у Prog Academy — це 5 модулів за 4 місяці: AI Start, QA Manual, QA Java, QA Automation і SQL. У модулі QA Manual є техніки тест-дизайну, тестова документація, баг-репорти, тестування API і Postman, а також розбір питань і завдань для підготовки до співбесіди на позицію QA Engineer.
Програма курсу QA →Веб, клієнт-сервер і тестування API
Що таке клієнт-серверна архітектура і що відбувається, коли ви відкриваєте сторінку?
У клієнт-серверній архітектурі клієнт (браузер або мобільний застосунок) надсилає запити, а сервер обробляє їх і повертає відповіді. Коротко за кроками:
- Браузер через DNS дізнається IP-адресу сервера за доменним ім'ям.
- Встановлює з'єднання, для HTTPS — із шифруванням TLS.
- Надсилає HTTP-запит: метод, адресу, заголовки, іноді тіло.
- Сервер обробляє запит, за потреби звертається до бази даних.
- Сервер повертає відповідь: код стану, заголовки й тіло (HTML, JSON, файл).
- Браузер будує сторінку і дозавантажує стилі, скрипти, зображення окремими запитами.
Що хочуть почути: розуміння, що дефект може бути на клієнті, на сервері або в даних, і що ви вмієте це розрізнити за вкладкою Network.
Які HTTP-методи ви знаєте і чим вони відрізняються?
Основні методи — GET (отримати дані), POST (створити ресурс або надіслати дані на обробку), PUT (повністю замінити ресурс), PATCH (частково змінити) і DELETE (видалити). Їхні властивості визначено в RFC 9110.
| Метод | Призначення | Безпечний | Ідемпотентний |
|---|---|---|---|
| GET | Отримання даних | Так | Так |
| POST | Створення ресурсу, надсилання даних на обробку | Ні | Ні |
| PUT | Повна заміна ресурсу | Ні | Так |
| PATCH | Часткова зміна ресурсу | Ні | Ні |
| DELETE | Видалення ресурсу | Ні | Так |
Безпечний метод не має змінювати стан сервера. Ідемпотентний — той, у якого кілька однакових запитів поспіль дають той самий стан сервера, що й один. Для тестувальника це готова перевірка: два однакові PUT не мають створити два об'єкти, а повторне надсилання POST через подвійний клік може створити дублікат замовлення.
Які коди відповідей HTTP потрібно знати?
Коди поділяються на п'ять класів: 1xx — інформаційні, 2xx — успіх, 3xx — перенаправлення, 4xx — помилка на боці клієнта, 5xx — помилка на боці сервера.
| Код | Значення |
|---|---|
| 200 OK | Запит виконано успішно |
| 201 Created | Ресурс створено |
| 204 No Content | Успіх, тіла відповіді немає |
| 301 / 302 | Постійне / тимчасове перенаправлення |
| 304 Not Modified | Ресурс не змінився, можна взяти з кешу |
| 400 Bad Request | Некоректний запит |
| 401 Unauthorized | Клієнт не автентифікований: немає дійсних облікових даних |
| 403 Forbidden | Сервер зрозумів запит, але відмовляється його виконувати, наприклад бракує прав |
| 404 Not Found | Ресурс не знайдено |
| 500 Internal Server Error | Непередбачена помилка на сервері |
| 502 / 503 | Помилка шлюзу / сервіс тимчасово недоступний |
Часте уточнювальне питання — різниця між 401 і 403: 401 означає «назвіться», 403 — «я знаю, хто ви, але вам сюди не можна». І ще одне правило: відповідь 500 на некоректні дані від користувача — це дефект, сервер має повернути зрозумілу помилку 4xx.
Чим cookies відрізняються від localStorage і sessionStorage?
Cookies браузер автоматично надсилає на сервер із кожним запитом до відповідного домену, а localStorage і sessionStorage доступні лише JavaScript на сторінці й самі на сервер не передаються.
| Cookies | localStorage | sessionStorage | |
|---|---|---|---|
| Надсилання на сервер | Автоматично із запитами | Ні | Ні |
| Термін життя | До дати завершення або до закриття браузера | Доки дані не видалять | Доки відкрита вкладка |
| Обсяг | Близько 4 КБ на одну cookie | Близько 5 МБ на джерело | Близько 5 МБ на джерело |
| Типове застосування | Сесія, авторизація | Налаштування інтерфейсу, чернетки | Дані одного візиту у вкладці |
У cookies є атрибути, про які варто згадати: HttpOnly закриває cookie від JavaScript, Secure дозволяє передавання лише через HTTPS, SameSite обмежує надсилання з чужих сайтів. Подробиці — у документації MDN про cookies та Web Storage API. Усе це видно у вкладці Application в DevTools.
Як ви використовуєте DevTools у роботі?
DevTools потрібні, щоб зрозуміти, на якому боці дефект, і додати до баг-репорту докази. Перелічіть вкладки і що ви в них робите.
- Network — запити й відповіді: метод, код стану, тіло, час; тут-таки імітація повільної мережі та вимкнення кешу.
- Console — помилки JavaScript, які часто пояснюють «кнопка не натискається».
- Elements — структура і стилі сторінки, перевірка верстки та локаторів.
- Application — cookies, localStorage і sessionStorage: переглянути, змінити, видалити.
- Режим пристроїв — перевірка адаптивної верстки на різних розмірах екрана.
Приклад: після натискання «Зберегти» нічого не відбувається. У Network видно запит із відповіддю 500 — дефект на сервері, додаю тіло відповіді. Запиту немає, а в Console помилка — дефект на клієнті. Довідка — у документації Chrome DevTools.
Що таке REST API і що ви перевіряєте у відповіді?
REST API — це інтерфейс, у якому клієнт працює з ресурсами за адресами (URL) за допомогою HTTP-методів, а дані найчастіше передаються у форматі JSON. Тестування API перевіряє логіку без інтерфейсу користувача.
Що перевіряти у відповіді:
- код стану — чи відповідає він сценарію;
- тіло відповіді — структура, обов'язкові поля, типи і значення;
- заголовки, наприклад
Content-Type; - час відповіді;
- стан системи після запиту: об'єкт справді створено, змінено або видалено (перевіряється наступним GET або запитом до бази даних).
І негативні сценарії: запит без токена, із чужим токеном, без обов'язкового поля, з неправильним типом даних, з неіснуючим ідентифікатором, зі значеннями на межах і за ними.
Як ви тестуєте API в Postman?
У Postman я збираю запити в колекцію, виношу адресу стенда і токени у змінні середовища та додаю до запитів автоматичні перевірки у скриптах. Колекцію можна запускати цілком і передавати колегам.
Мінімальний приклад перевірок у вкладці скриптів запиту (виконуються після отримання відповіді):
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response contains user id", function () {
const body = pm.response.json();
pm.expect(body.id).to.eql(1);
});
Синтаксис описано в документації Postman. Що хочуть почути: що ви перевіряєте не лише код 200, а й вміст відповіді, і вмієте зв'язати запити в ланцюжок — наприклад, зберегти ідентифікатор створеного об'єкта у змінну і використати його в наступному запиті.
SQL і мобільне тестування
Усі запити нижче виконано в SQLite на невеликій навчальній базі інтернет-магазину. Її можна створити в себе і повторити приклади. Якщо SQL для вас поки нова тема, почніть зі статті SQL для початківців або безкоштовного курсу з SQL.
CREATE TABLE users (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
email TEXT NOT NULL,
city TEXT
);
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
user_id INTEGER NOT NULL REFERENCES users(id),
amount INTEGER NOT NULL,
status TEXT NOT NULL
);
INSERT INTO users (id, name, email, city) VALUES
(1, 'Olena', '[email protected]', 'Kyiv'),
(2, 'Taras', '[email protected]', 'Lviv'),
(3, 'Iryna', '[email protected]', 'Kyiv'),
(4, 'Maksym', '[email protected]', NULL),
(5, 'Sofiia', '[email protected]', 'Odesa');
INSERT INTO orders (id, user_id, amount, status) VALUES
(101, 1, 1200, 'paid'),
(102, 1, 450, 'paid'),
(103, 2, 900, 'cancelled'),
(104, 3, 2500, 'paid'),
(105, 3, 300, 'new'),
(106, 3, 700, 'paid');
Навіщо тестувальнику SQL і як вибрати дані з таблиці?
SQL потрібен тестувальнику, щоб перевірити, що дані справді збереглися в базі так, як показує інтерфейс, і щоб підготувати або знайти тестові дані. Базовий запит — SELECT із фільтром WHERE і сортуванням ORDER BY.
SELECT id, name, city
FROM users
WHERE city = 'Kyiv'
ORDER BY name;
id name city
-- ----- ----
3 Iryna Kyiv
1 Olena Kyiv
Типова помилка: порівнювати з NULL через знак рівності. Умова city = NULL не поверне жодного рядка, правильно — city IS NULL.
Чим INNER JOIN відрізняється від LEFT JOIN?
INNER JOIN повертає лише ті рядки, для яких знайшлася пара в обох таблицях; LEFT JOIN повертає всі рядки лівої таблиці, а там, де пари немає, підставляє NULL.
INNER JOIN — оплачені замовлення з іменами покупців:
SELECT u.name, o.id AS order_id, o.amount, o.status
FROM users u
INNER JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
ORDER BY o.amount DESC;
name order_id amount status
----- -------- ------ ------
Iryna 104 2500 paid
Olena 101 1200 paid
Iryna 106 700 paid
Olena 102 450 paid
LEFT JOIN — кількість замовлень у кожного користувача, включно з тими, у кого замовлень немає:
SELECT u.name, COUNT(o.id) AS orders_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY orders_count DESC, u.name;
name orders_count
------ ------------
Iryna 3
Olena 2
Taras 1
Maksym 0
Sofiia 0
З INNER JOIN Maksym і Sofiia до результату не потрапили б узагалі. Зверніть увагу на COUNT(o.id): він рахує лише рядки, де значення не NULL, тому в користувачів без замовлень виходить 0, а не 1.
Що робить GROUP BY і чим WHERE відрізняється від HAVING?
GROUP BY об'єднує рядки в групи, щоб порахувати для кожної агрегат — COUNT, SUM, AVG, MIN, MAX. WHERE фільтрує рядки до групування, HAVING — групи після нього.
SELECT u.name, COUNT(o.id) AS orders_count, SUM(o.amount) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
GROUP BY u.id, u.name
HAVING SUM(o.amount) > 2000;
name orders_count total
----- ------------ -----
Iryna 2 3200
Тут WHERE спершу залишив лише оплачені замовлення, GROUP BY зібрав їх за покупцями, а HAVING відібрав тих, у кого сума більша за 2000. В Olena сума оплачених замовлень 1650, тому її в результаті немає. Синтаксис — у документації SQLite щодо SELECT.
У чому особливості тестування мобільних застосунків?
Мобільний застосунок працює на безлічі пристроїв із різними екранами та версіями ОС, у нестабільній мережі й постійно переривається зовнішніми подіями, і все це потрібно перевіряти додатково до функціональності.
- Типи застосунків: нативні (написані під конкретну платформу), вебзастосунки (відкриваються в браузері) та гібридні (вебвміст усередині нативної оболонки).
- Переривання: вхідний дзвінок, сповіщення, згортання і повернення, блокування екрана, розряджання батареї.
- Мережа: перемикання між Wi-Fi і мобільною мережею, слабкий сигнал, режим польоту, робота офлайн.
- Дозволи: камера, геолокація, сповіщення — що відбувається в разі відмови і в разі відкликання дозволу в налаштуваннях.
- Пристрій: поворот екрана, різні розміри та щільність екранів, темна тема, розмір системного шрифту.
- Життєвий цикл: встановлення, оновлення поверх старої версії зі збереженням даних, видалення.
Про пристрої: емулятор Android і симулятор iOS зручні для швидких перевірок верстки та логіки на різних версіях ОС, але перед релізом ключові сценарії проходять на реальних пристроях — продуктивність, камеру, жести, сповіщення і поведінку мережі на емуляторі достовірно не перевірити. Інструменти описано в документації Android Emulator та Xcode.
Основи автоматизації та AI-інструменти
Від ручного тестувальника не чекають готового фреймворку, але чекають розуміння, навіщо потрібна автоматизація тестування і де її межі.
Що варто автоматизувати, а що ні?
Автоматизувати варто стабільні перевірки, які часто повторюються і мають однозначний очікуваний результат; не варто — те, що часто змінюється, виконується один раз або потребує людської оцінки.
| Добрі кандидати | Погані кандидати |
|---|---|
| Регресійні та smoke-перевірки | Функціональність, яка ще активно змінюється |
| Перевірки API | Разові перевірки |
| Один сценарій на великому наборі даних | Зручність використання і зовнішній вигляд «на око» |
| Критичні для бізнесу сценарії: вхід, оплата | Дослідницьке тестування |
Що хочуть почути: що автоматизація — це інвестиція: тест потрібно написати і потім підтримувати, тому рішення ухвалюють за співвідношенням витрат і користі, а не за принципом «автоматизуємо все».
Що таке піраміда тестування?
Піраміда тестування — це модель розподілу автотестів за рівнями: в основі багато швидких модульних тестів, посередині менше інтеграційних (зокрема тестів API), на вершині небагато повільних наскрізних тестів через інтерфейс користувача.
Логіка проста: що вищий рівень, то тест повільніший, дорожчий у підтримці й менш стабільний, зате ближчий до реального сценарію користувача. Зворотна ситуація, коли майже всі автотести йдуть через інтерфейс, призводить до довгих і крихких прогонів. Класичний опис — у нотатці Мартіна Фаулера Test Pyramid.
Чим Selenium відрізняється від Playwright?
Обидва інструменти керують браузером із коду. Selenium WebDriver працює через стандартизований W3C протокол WebDriver; Playwright — новіший інструмент із вбудованим автоматичним очікуванням елементів і власним тест-ранером.
| Selenium WebDriver | Playwright | |
|---|---|---|
| Мови | Java, Python, C#, JavaScript, Ruby, Kotlin | JavaScript/TypeScript, Python, Java, .NET |
| Браузери | Chrome, Firefox, Edge, Safari через драйвери браузерів | Рушії Chromium, Firefox і WebKit |
| Очікування | Налаштовуються в коді тесту (явні й неявні) | Перед дією автоматично перевіряється, що елемент готовий до неї |
| Тест-ранер | Зовнішній: JUnit, TestNG, pytest та інші | Власний Playwright Test |
Джерела: документація Selenium WebDriver та опис автоочікувань Playwright. Порівнювати «що краще» на співбесіді не потрібно: вибір залежить від стека проєкту, а принципи — локатори, очікування, незалежність тестів — однакові.
Який вигляд має простий автотест?
Будь-який автотест повторює структуру ручного тест-кейсу: підготовка, дії та перевірка очікуваного результату. Нижче тест на Playwright для негативного сценарію входу: неправильний пароль має показати повідомлення про помилку і залишити користувача на сторінці логіну.
const { test, expect } = require('@playwright/test');
test('login with a wrong password shows an error', async ({ page }) => {
await page.goto('/login.html');
await page.getByLabel('Email').fill('[email protected]');
await page.getByLabel('Password').fill('wrong-password');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('alert')).toHaveText('Invalid email or password');
await expect(page).toHaveURL(/login/);
});
Тест перевірено на навчальній сторінці з формою входу; адресу стенда задає параметр baseURL у конфігурації. Вивід запуску:
Running 1 test using 1 worker
✓ 1 tests/login.spec.js:3:1 › login with a wrong password shows an error (177ms)
1 passed (1.4s)
Що варто вміти пояснити: елементи знайдено за підписом і роллю, тобто так, як їх бачить користувач, а не за крихкими CSS-класами (рекомендації щодо локаторів); у тесті немає пауз на кшталт «зачекати 3 секунди» — перевірка expect сама чекає потрібного стану. Тест, який то проходить, то падає без змін у коді, називають нестабільним (flaky); найчастіші причини — жорсткі паузи, залежність від інших тестів і спільні тестові дані.
Як ви використовуєте AI-інструменти в тестуванні?
Я використовую AI-асистента як помічника для чорнової роботи і завжди перевіряю результат сама: відповідальність за тести залишається на тестувальникові.
- Де допомагає: накидати тест-кейси і чек-лист за вимогою, знайти пропущені негативні сценарії, згенерувати тестові дані, скласти SQL-запит або регулярний вираз, розібрати лог чи трасування помилки, переформулювати баг-репорт.
- Де помиляється: вигадує вимоги, яких немає, упевнено видає неправильні факти, не знає контексту вашого продукту і бізнес-правил.
- Чого робити не можна: надсилати до публічних сервісів персональні дані користувачів, ключі доступу і закритий код, якщо це не дозволено правилами компанії.
Що хочуть почути: конкретний приклад із вашої практики і те, як саме ви перевірили результат асистента. Як AI змінює професію загалом, розібрано у статті QA Engineer в епоху AI.
Практичні завдання з розв'язками
На практичній частині оцінюють не кількість ідей, а структуру: спершу уточнювальні запитання, потім групи перевірок, потім пріоритети. Нижче п'ять типових завдань.
Завдання 1. Протестуйте форму входу
Дано форму: email, пароль, кнопка «Увійти», посилання «Забули пароль?». Почніть із запитань: які вимоги до email і пароля, чи є блокування після кількох невдалих спроб, скільки живе сесія. Потім розкладіть перевірки за групами.
| Група | Перевірки |
|---|---|
| Позитивні | Вхід із правильними даними; email в іншому регістрі; вхід клавішею Enter; перехід за посиланням відновлення пароля |
| Негативні | Неправильний пароль; незареєстрований email; порожні поля; email без символу @; пробіли на початку і в кінці |
| Межі | Пароль мінімальної та максимальної довжини і на один символ коротший та довший |
| Безпека | Пароль приховано під час введення; повідомлення про помилку не розкриває, що саме неправильне — email чи пароль; обмеження кількості спроб; дані передаються через HTTPS; після виходу кнопка «Назад» не повертає до особистого кабінету |
| Інтерфейс і зручність | Порядок переходу клавішею Tab; зрозумілі тексти помилок; відображення на мобільному екрані; робота менеджера паролів |
| Сесія | Вхід у двох вкладках; завершення сесії; поведінка після зміни пароля на іншому пристрої |
Завдання 2. Протестуйте олівець (або ліфт)
Завдання перевіряє не знання олівців, а спосіб мислення. Правильний початок — запитання: для кого він і для чого, які до нього вимоги, простий він чи механічний, чи є гумка. Без вимог неможливо сказати, що є дефектом.
Потім покажіть структуру за типами тестування:
- Функціональне: пише на папері; лінія потрібної товщини й кольору; загострюється; гумка стирає слід.
- Зручність використання: зручно тримати, не скочується зі столу, маркування твердості читається.
- Надійність і навантаження: грифель не ламається за звичайного натиску; що відбувається за сильного натиску і після падіння зі столу.
- Сумісність: різні види паперу, різні стругачки.
- Негативні сценарії: письмо на мокрій або глянцевій поверхні, використання на морозі.
- Безпека: нетоксичні матеріали, відсутність скалок.
Для ліфта логіка та сама, але додаються стани й переходи: двері відчинені або зачинені, кабіна рухається або стоїть, виклики з кількох поверхів одночасно, перевантаження, вимкнення живлення. Це добра нагода застосувати тестування переходів станів.
Завдання 3. Напишіть тест-кейси за вимогою
Вимога: «Під час реєстрації пароль має містити від 8 до 64 символів, щонайменше одну латинську літеру і щонайменше одну цифру. У разі порушення правила під полем показується повідомлення про помилку, акаунт не створюється».
| № | Перевірка | Тестові дані | Очікуваний результат |
|---|---|---|---|
| 1 | Припустимий пароль мінімальної довжини | 8 символів: літери й цифра | Акаунт створено |
| 2 | Припустимий пароль максимальної довжини | 64 символи: літери й цифра | Акаунт створено |
| 3 | Пароль коротший за мінімум | 7 символів: літери й цифра | Повідомлення про помилку, акаунт не створено |
| 4 | Пароль довший за максимум | 65 символів: літери й цифра | Повідомлення про помилку, акаунт не створено |
| 5 | Пароль без цифр | 10 латинських літер | Повідомлення про помилку, акаунт не створено |
| 6 | Пароль без літер | 10 цифр | Повідомлення про помилку, акаунт не створено |
| 7 | Порожнє поле | — | Повідомлення про помилку, акаунт не створено |
І обов'язково назвіть запитання до вимоги — це часто цінніше за самі кейси: чи дозволені спецсимволи, пробіли й кирилиця; чи вважається кирилична літера «літерою»; чи враховується регістр; чи обрізаються пробіли по краях; який точний текст повідомлення.
Завдання 4. Знайдіть граничні значення для поля
Вимога: «Поле „Кількість“ у кошику приймає цілі числа від 1 до 99».
- Класи еквівалентності: менше за 1 (неприпустимий), від 1 до 99 (припустимий), більше за 99 (неприпустимий).
- Граничні значення, двозначний варіант: 0, 1, 99, 100.
- Тризначний варіант: 0, 1, 2 і 98, 99, 100.
- Неприпустимі класи поза числовою віссю: порожнє поле, від'ємне число, дробове число (1,5), літери, пробіл, дуже велике число.
Додатковий бал — помітити те, чого у вимозі немає: що відбувається, якщо на складі залишилося менше товару, ніж введено, і чи можна змінити значення в полі в обхід кнопок «плюс» і «мінус».
Завдання 5. Напишіть SQL-запити
Використовується база з розділу про SQL. Перша частина: знайдіть користувачів, у яких немає жодного замовлення.
SELECT u.id, u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL
ORDER BY u.id;
id name
-- ------
4 Maksym
5 Sofiia
Друга частина: знайдіть email, які трапляються в таблиці користувачів більше ніж один раз. Це типова перевірка тестувальника — переконатися, що в базі немає дублікатів там, де значення має бути унікальним.
SELECT email, COUNT(*) AS cnt
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
email cnt
----------------- ---
[email protected] 2
Типові помилки кандидатів
Найчастіше кандидатів підводить не незнання визначень, а невміння застосувати їх до прикладу. Перелік складено з досвіду авторки.
- Визначення без прикладу. «Валідація — це перевірка відповідності очікуванням користувача» і тиша. Одразу додавайте випадок із практики або навчального проєкту.
- Тестування без запитань. Кандидат одразу перелічує перевірки для форми, не спитавши про жодну вимогу.
- Лише позитивні сценарії. Немає негативних перевірок, меж і заборонених переходів.
- Плутанина в термінах. Severity і priority, рівні й типи тестування, повторне і регресійне тестування.
- Розмитий баг-репорт. Заголовок «не працює», кроки «зайти і перевірити», очікуваного результату немає.
- Відсутність пріоритетів. Тридцять перевірок одним списком без відповіді на питання «що ви перевірите першим, якщо є десять хвилин».
- Завчені відповіді. Перше ж уточнювальне питання показує, що за текстом немає розуміння.
- Інструменти «в резюме». Postman і SQL вказано, але кандидат не може надіслати запит або написати JOIN.
- Позиція «розробник — супротивник». Інтерв'юер шукає людину, яка допомагає команді, а не виграє суперечки.
- Немає запитань до компанії. Це читається як брак інтересу до роботи.
Що запитати в інтерв'юера?
Запитання кандидата показують, що він розуміє, як влаштована робота тестувальника, і допомагають самому оцінити команду. Оберіть п'ять-шість із переліку.
- Скільки тестувальників у команді і яке співвідношення з розробниками?
- Як влаштований процес: Scrum, Kanban, яка довжина спринту, як проходить реліз?
- Хто пише вимоги і на якому етапі тестувальник долучається до задачі?
- Яку тестову документацію ведуть: тест-кейси, чек-листи, у якому інструменті?
- Чи є автоматизація, на якому стеку і чи може ручний тестувальник у ній розвиватися?
- Які тестові середовища є і як туди потрапляють збірки?
- Який вигляд має онбординг і чи буде в мене наставник у перші місяці?
- За якими критеріями оцінюють роботу тестувальника і як відбувається перегляд рівня?
- Які правила використання AI-інструментів прийнято в команді?
- Які задачі я отримаю в перший місяць?
План підготовки на два тижні
План розраховано на годину-дві на день і на людину, яка вже пройшла навчання і повторює матеріал. Це авторський орієнтир: теми, у яких ви впевнені, скорочуйте, слабкі — розтягуйте.
| Дні | Тема | Що зробити |
|---|---|---|
| 1–2 | Теорія тестування | Повторити терміни за глосарієм ISTQB, до кожного із семи принципів і кожного рівня записати власний приклад |
| 3–4 | Техніки тест-дизайну | Взяти три форми на реальних сайтах і для кожної виписати класи еквівалентності, межі та одну таблицю рішень |
| 5 | Документація | Написати п'ять тест-кейсів і три баг-репорти для будь-якого застосунку, яким ви користуєтеся; попросити когось відтворити дефект за вашим репортом |
| 6 | Процеси | Прочитати Scrum Guide, підготувати відповідь про роль тестувальника у спринті та про критерії завершення тестування |
| 7 | Повторення | Відповісти вголос на питання перших чотирьох блоків, записати себе і прослухати |
| 8–9 | Веб та API | Відкрити DevTools на будь-якому сайті й розібрати запити у вкладці Network; надіслати в Postman GET, POST і DELETE до відкритого навчального API і додати перевірки |
| 10 | SQL | Створити базу з цієї статті й написати з пам'яті запити з WHERE, JOIN, GROUP BY і HAVING |
| 11 | Мобільне тестування та автоматизація | Скласти чек-лист мобільних перевірок для одного застосунку; повторити піраміду тестування і критерії вибору тестів для автоматизації |
| 12 | Практичні завдання | Розв'язати п'ять завдань із розділу з практикою письмово, з обмеженням у часі |
| 13 | Пробна співбесіда | Провести пробне інтерв'ю з колегою або одногрупником; підготувати розповідь про себе і запитання до компанії |
| 14 | Резюме і прогалини | Перевірити, що все вказане в резюме ви можете показати на практиці; повторити питання, на які відповідали невпевнено |
Якщо після співбесід стає зрозуміло, що бракує системної бази, її дає курс QA. Наступний крок після впевненого ручного тестування — курс QA Automation.
Часті запитання
Скільки часу потрібно на підготовку до співбесіди на Junior QA?
Якщо теорію і практику вже пройдено, на повторення зазвичай вистачає двох тижнів по годині-дві на день: тиждень на теорію, тест-дизайн і документацію, тиждень на веб, API, SQL і пробні співбесіди. Це орієнтир авторки, а не статистика. Якщо ви жодного разу не писали тест-кейси та баг-репорти власноруч, спершу потрібна практика, і на неї піде більше часу.
Чи потрібно знати програмування для співбесіди на ручного тестувальника?
Для позиції ручного тестувальника писати код зазвичай не просять. Але від кандидата чекають технічної грамотності: розуміти клієнт-серверну архітектуру, читати JSON, користуватися DevTools і Postman, писати прості SQL-запити. Базове розуміння того, що таке автотест і що варто автоматизувати, буде плюсом.
Чи потрібен сертифікат ISTQB, щоб пройти співбесіду?
Сертифікат не є обов'язковою умовою, якщо його прямо не вказано у вакансії. Значно важливіше знати термінологію ISTQB: питання з теорії майже завжди спираються на програму Foundation Level, і відповіді в цих термінах звучать упевненіше, ніж переказ своїми словами.
Який рівень англійської потрібен тестувальнику на співбесіді?
Потрібна англійська, достатня для читання вимог і документації та для письмового опису дефекту: баг-репорти в багатьох командах пишуть англійською. Якщо у вакансії вказано розмовний рівень, частину співбесіди проведуть англійською, тому заздалегідь потренуйтеся розповідати про себе і про свій навчальний проєкт.
Чи дають тестове завдання і як його виконувати?
Часто дають: протестувати сайт або форму, написати тест-кейси за вимогою, оформити кілька баг-репортів. Оцінюють не кількість знайдених дефектів, а хід думки й акуратність оформлення: зрозумілі заголовки, кроки відтворення, очікуваний і фактичний результат, розставлені пріоритети. Обов'язково напишіть, що ви перевірили і що залишилося поза межами.
Чи можна користуватися AI-інструментами на співбесіді та в тестовому завданні?
Залежить від правил компанії, тому запитайте про це прямо. У тестовому завданні асистента часто дозволяють як помічника, але за результат відповідаєте ви: кожен тест-кейс і кожен баг-репорт треба вміти пояснити. Під час живої розмови читати відповіді з екрана не варто: це помітно й оцінюється гірше, ніж чесне «не знаю».
Що робити, якщо не знаєте відповіді на питання?
Скажіть про це прямо і покажіть, як міркуєте: що ви знаєте про суміжну тему, як шукали б відповідь, що перевірили б насамперед. Для тестувальника вміння уточнювати й міркувати вголос важливіше за завчене визначення. Вигадана відповідь гірша, ніж визнання прогалини.
Чи питають SQL та API на співбесіді Junior QA?
Так, у більшості вакансій на тестування вебзастосунків це входить до очікуваної бази. Зазвичай достатньо вміти написати SELECT із фільтром, JOIN двох таблиць і GROUP BY, пояснити HTTP-методи та коди відповідей і показати, як ви надсилаєте запит у Postman і що перевіряєте у відповіді.
Що відповідати на питання про зарплатні очікування?
Назвіть вилку, а не одну цифру, і спирайтеся на свіжі відкриті дані про ринок для свого рівня, а не на чутки. Додайте, що готові обговорювати суму з урахуванням завдань та умов. Відмова називати очікування зазвичай виглядає гірше, ніж спокійна аргументована відповідь.
Джерела
- ISTQB Glossary — глосарій термінів тестування
- ISTQB: Certified Tester Foundation Level, програма v4.0
- Ken Schwaber, Jeff Sutherland: The Scrum Guide
- RFC 9110: HTTP Semantics — методи та коди стану
- MDN: Using HTTP cookies
- MDN: Web Storage API
- Chrome DevTools documentation
- Postman documentation: Write scripts to test API response data
- SQLite documentation: SELECT
- Node.js documentation: Test runner
- Playwright documentation: Auto-waiting
- Playwright documentation: Locators
- Selenium documentation: WebDriver
- Martin Fowler: Test Pyramid
- Android Developers: Run apps on the Android Emulator
- Apple Developer: Running your app in Simulator or on a device
