Співбесіда на Manual QA перевіряє знання теорії тестування, технік тест-дизайну та вміння писати баг-репорти, з якими розробник справді може працювати. Нижче — питання, які ставлять найчастіше на рівні Junior і Middle, кожне з еталонною відповіддю. Middle: глибше розуміння, оптимізацію та реальні робочі ситуації.
Еквівалентне розбиття ділить вхідні дані на групи, де всі значення поводяться однаково, тож достатньо перевірити по одному значенню з групи. Для поля віку 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, а повідомлення про помилку не розкривають, чи існує такий логін.
Тестування показує наявність дефектів, але не доводить їх відсутність; вичерпне тестування неможливе; раннє тестування економить час і гроші; дефекти накопичуються в невеликій кількості модулів; парадокс пестициду — повторювані тести перестають знаходити нові баги; тестування залежить від контексту; хибність відсутності помилок — софт без відомих дефектів усе одно марний, якщо вирішує не ту задачу.
Таблиця прийняття рішень зіставляє комбінації вхідних умов з очікуваними діями системи. Її застосовують, коли поведінка залежить від кількох взаємодіючих умов — наприклад знижка залежить від типу клієнта, суми замовлення та промокоду. Таблиця робить пропущені комбінації очевидними і напряму перетворюється на тест-кейси, тому це стандартна техніка для складної бізнес-логіки.
Тест-кейс описує точні кроки, тестові дані й очікуваний результат — його може повторити будь-хто, і він підходить для регульованої або складної функціональності. Чек-лист — це перелік того, що треба перевірити, без приписаних кроків, з опорою на досвід тестувальника. Чек-листи швидше писати й підтримувати, вони добрі для дослідницької роботи та стабільних областей; тест-кейси потрібні для онбордингу, аудитів і фіч, де важливий точний сценарій.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Middle QA Manual →