Співбесіда на Manual QA перевіряє знання теорії тестування, технік тест-дизайну та вміння писати баг-репорти, з якими розробник справді може працювати. Нижче — питання, які ставлять найчастіше на рівні Junior і Middle, кожне з еталонною відповіддю. Middle: глибше розуміння, оптимізацію та реальні робочі ситуації.
Відбирають за ризиком, а не за покриттям. Це означає: що змінювалося в цьому релізі і що цього стосується, сценарії, втрата яких коштує грошей — авторизація, оформлення замовлення, оплата, — і ділянки з найбагатшою історією дефектів. І вголос проговорюють, що не запускалося, щоб рішення випускати було командним, а не мовчки вашим.
Наодинці таке не вирішується, але формулюєте ви: скільки користувачів зачіпає, як часто, чи є обхідний шлях, що може зламати сам фікс. Косметичне зміщення на рідкісному екрані при завтрашньому релізі — законне «не зараз». Незаконно тихо закрити: баг іде в беклог разом з обґрунтуванням, інакше його знаходитимуть заново щокварталу.
Виходьте з того, що різняться оточення, а не що тест неправильний. Порівняйте дані, конфігурацію, фіче-прапорці, версії та тайминги — стейдж зазвичай повільніший, і це розкриває гонки та неявні очікування. Потім перевірте, чи не залежить тест від стану, який лишив інший тест. Оголосити флакі й перезапустити — це спосіб перетворити справжній баг оточення на вічно ігнорований червоний.
Коди відповідей для успіху й для помилок, схему відповіді та типи, обовʼязкові й необовʼязкові поля, поведінку за відсутніх, зайвих і невірно типізованих полів. Далі авторизацію — той самий запит без токена і з чужим токеном. І межі: порожні масиви, величезні payload-и та повторні виклики, бо ідемпотентність — це місце, де ховаються баги API.
Не чекати ідеальних вимог, а зробити невизначеність видимою. Записати, як ви зрозуміли задачу, перелічити випадки, на які спека не відповідає, і віднести це аналітику чи власнику продукту до того, як будувати кейси на здогадці. Питання, поставлене до кінця розробки, коштує розмови; те саме питання після — переробки.
Вона каже, що більшість перевірок мають бути швидкими юніт-тестами, менше інтеграційних і зовсім мало повільних наскрізних. Для ручного QA наслідок такий: час витрачається марно, якщо ви вручну переперевіряєте те, що вже покрито юнітом. Ручні зусилля потрібні там, де людина краща за машину — дослідницьке тестування, юзабіліті та сценарії, які ніхто не додумався автоматизувати.
Баг — це поведінка, що суперечить вимозі, специфікації або розумному очікуванню користувача. Фічереквест просить поведінку, про яку не домовлялися. Сіра зона — третій випадок, коли спека мовчить, а поведінка погана, і сперечатися там про ярлик означає марнувати час. Опишіть вплив, ярлик хай обере власник продукту, а ваша задача — щоб знахідка не загубилася в будь-якому разі.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Middle QA Manual →