Співбесіда на Manual QA перевіряє знання теорії тестування, технік тест-дизайну та вміння писати баг-репорти, з якими розробник справді може працювати. Нижче — питання, які ставлять найчастіше на рівні Junior і Middle, кожне з еталонною відповіддю. Junior: базова теорія, визначення та прості практичні кейси.
Верифікація відповідає на питання «чи правильно ми робимо продукт?» — перевіряє роботу на відповідність специфікаціям і проєктній документації, зазвичай через ревʼю та статичний аналіз. Валідація відповідає «чи той продукт ми робимо?» — перевіряє, що готове ПЗ справді вирішує задачу користувача, через динамічне тестування. Верифікація триває протягом усієї розробки, валідація — проти реальних вимог і користувачів.
Еквівалентне розбиття ділить вхідні дані на групи, де всі значення поводяться однаково, тож достатньо перевірити по одному значенню з групи. Для поля віку 1–120 класи такі: валідний 1–120, невалідний знизу (0 і відʼємні), невалідний зверху (121 і більше), невалідний тип (літери, символи, порожнє поле). Виходить чотири тести замість ста двадцяти.
Аналіз граничних значень перевіряє краї кожного класу, бо саме там накопичуються помилки на одиницю. Для поля 1–100 перевіряють 0, 1, 2 на нижній межі та 99, 100, 101 на верхній. Техніку майже завжди застосовують разом з еквівалентним розбиттям: класи показують, які групи є, а межі — де вони ламаються.
Severity описує технічний вплив дефекту на систему, Priority — наскільки терміново бізнес хоче його виправити. Їх виставляють різні люди: Severity зазвичай тестувальник, Priority — продакт або менеджер. Падіння в рідко використовуваному адмінському експорті — висока Severity і низький Priority; помилка в назві компанії на головній — низька Severity і високий Priority.
Дефект зазвичай проходить New → Assigned → Open (в роботі) → Fixed → Retest → Closed. Альтернативні результати: Rejected (не дефект), Duplicate, Deferred (відкладено на наступний реліз) та Reopened, якщо ретест показав, що фікс не спрацював. Конкретні статуси залежать від команди, але важливо, що кожен баг завершується в термінальному стані із зафіксованою причиною.
Smoke — поверхнева широка перевірка, що збірка взагалі придатна до тестування: якщо зламаний логін, тестування зупиняють. Sanity — вузька і глибока: після конкретного фіксу перевіряють, що одна область працює як треба. Regression — широка й повторювана: підтверджує, що нові зміни не зламали раніше робочу функціональність, і це головний кандидат на автоматизацію.
Exploratory testing — це одночасне проєктування та виконання тестів: тестувальник вивчає продукт і на основі знахідок вирішує, що пробувати далі. Воно структуроване: є чартер, таймбокс і нотатки. Ad-hoc тестування неструктуроване й не документується, йде суто на інтуїції. Exploratory відтворюване і про нього можна звітувати, ad-hoc — ні.
Робочий баг-репорт містить зрозумілий заголовок, оточення (збірка, ОС, браузер, пристрій), передумови, кроки відтворення, фактичний результат, очікуваний результат, severity, priority і вкладення — скриншоти або логи. Кроки відтворення найважливіші, бо дефект, який розробник не може відтворити, зазвичай закривають як «не відтворюється», і репорт втрачає всю цінність.
Тест-план описує, як буде організовано тестування проєкту або релізу. Типові розділи: скоуп (що тестуємо і що не тестуємо), підхід і рівні тестування, критерії входу та виходу, оточення й тестові дані, ролі та відповідальність, графік, ризики та заходи їх зниження, артефакти. Це управлінський документ — мета в тому, щоб будь-хто міг побачити, що буде протестовано, ким і коли тестування вважається завершеним.
Позитивні: валідні дані пускають у систему і коректно редиректять, «запамʼятати мене» зберігає сесію, відновлення пароля працює від початку до кінця. Негативні: невірний пароль, неіснуючий користувач, порожні поля, SQL-інʼєкції та XSS, пробіли на початку й у кінці, регістр символів, дуже довгий ввід, блокування після кількох невдалих спроб. Плюс нефункціональне: пароль замаскований, форма працює на мобільному, дані йдуть через HTTPS, а повідомлення про помилку не розкривають, чи існує такий логін.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Junior QA Manual →