Співбесіда на Manual QA перевіряє знання теорії тестування, технік тест-дизайну та вміння писати баг-репорти, з якими розробник справді може працювати. Нижче — питання, які ставлять найчастіше на рівні Junior і Middle, кожне з еталонною відповіддю. Junior: базова теорія, визначення та прості практичні кейси.
Верифікація відповідає на питання, чи правильно ми побудували продукт — чи відповідає він специфікації, дизайну, погодженим вимогам. Валідація відповідає, чи той продукт ми побудували — чи розвʼязує він справжню задачу користувача. Фіча може повністю пройти верифікацію і провалити валідацію: саме так команди випускають те, що збігається зі спекою і нікому не потрібне.
Вхід ділиться на класи, всередині яких поведінка має бути однаковою, і з кожного береться одне значення замість перебору всіх. Тут виходить три класи: менше 18, від 18 до 65, більше 65, плюс невалідні — літери, порожньо, відʼємні. Сенс у покритті без надлишковості: якщо 30 пройшло, то 31 не дає нової інформації.
Дефекти скупчуються на межах діапазону, бо там живуть помилки на одиницю і переплутані знаки порівняння. Для поля від 18 до 65 перевіряють 17, 18, 19 і 64, 65, 66. Розбиття каже, які діапазони існують, а граничний аналіз — де всередині них реально знаходяться баги.
Робочий репорт містить заголовок, з якого зрозуміло що зламано, точні кроки відтворення, очікуваний і фактичний результат, оточення та доказ — скріншот, відео або лог. Марним його робить пропущена передумова або крок, який репортер зробив не помітивши: розробник не відтворює і закриває з формулюванням «у мене працює».
Severity — це технічний вплив, priority — наскільки терміново лагодити, і призначають їх різні люди: severity тестувальник, priority власник продукту. Одрук у назві компанії на лендингу — низька severity і найвищий priority. Падіння в адмінському екрані, яким користуються двічі на рік, — висока severity і низький priority.
Ні, і це один із семи принципів ISTQB. Тестування показує наявність дефектів, але ніколи не доводить їх відсутність, бо вичерпний перебір усіх входів і шляхів неможливий для будь-якої реальної системи. Тестування дає підстави вирішити, чи прийнятний ризик, а не гарантію.
Тест-кейс прописує передумови, кроки та очікуваний результат, тому його будь-хто пройде однаково. Чек-лист просто називає, що перевірити, лишаючи «як» на розсуд тестувальника. Кейси окупаються на регульованих і високоризикових сценаріях та для нових людей у команді, чек-листи виграють в дослідницькому тестуванні та в команді, яка знає систему, — там повні кейси перетворюються на документацію, яку ніхто не оновлює.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Junior QA Manual →