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