Собеседование на Manual QA проверяет знание теории тестирования, техник тест-дизайна и умение писать баг-репорты, с которыми разработчик реально может работать. Ниже — вопросы, которые задают чаще всего на уровне Junior и Middle, каждый с эталонным ответом. Middle: более глубокое понимание, оптимизацию и реальные рабочие ситуации.
Отбирают по риску, а не по покрытию. Это значит: что менялось в этом релизе и что этого касается, сценарии, потеря которых стоит денег — авторизация, оформление заказа, оплата, — и области с самой богатой историей дефектов. И вслух проговаривают, что не запускалось, чтобы решение выпускать было командным, а не молча вашим.
В одиночку такое не решается, но формулируете вы: сколько пользователей задевает, как часто, есть ли обходной путь, что может сломать сам фикс. Косметическое смещение на редком экране при завтрашнем релизе — законное «не сейчас». Незаконно тихо закрыть: баг уходит в бэклог вместе с обоснованием, иначе его будут заново находить каждый квартал.
Исходите из того, что различаются окружения, а не что тест неправильный. Сравните данные, конфигурацию, фиче-флаги, версии и тайминги — стейдж обычно медленнее, и это вскрывает гонки и неявные ожидания. Затем проверьте, не зависит ли тест от состояния, оставленного другим тестом. Объявить флаки и перезапустить — это способ превратить настоящий баг окружения в вечно игнорируемый красный.
Коды ответов для успеха и для ошибок, схему ответа и типы, обязательные и необязательные поля, поведение при отсутствующих, лишних и неверно типизированных полях. Дальше авторизацию — тот же запрос без токена и с чужим токеном. И границы: пустые массивы, огромные payload-ы и повторные вызовы, потому что идемпотентность — это место, где прячутся баги API.
Не ждать идеальных требований, а сделать неопределённость видимой. Записать, как вы поняли задачу, перечислить случаи, на которые спека не отвечает, и отнести это аналитику или владельцу продукта до того, как строить кейсы на догадке. Вопрос, заданный до конца разработки, стоит разговора; тот же вопрос после — переделки.
Она говорит, что большинство проверок должны быть быстрыми юнит-тестами, меньше интеграционных и совсем мало медленных сквозных. Для ручного QA следствие такое: время тратится зря, если вы вручную перепроверяете то, что уже покрыто юнитом. Ручные усилия нужны там, где человек лучше машины — исследовательское тестирование, юзабилити и сценарии, которые никто не додумался автоматизировать.
Баг — это поведение, противоречащее требованию, спецификации или разумному ожиданию пользователя. Фичереквест просит поведение, о котором не договаривались. Серая зона — третий случай, когда спека молчит, а поведение плохое, и спорить там о ярлыке значит терять время. Опишите влияние, ярлык пусть выберет владелец продукта, а ваша задача — чтобы находка не потерялась в любом случае.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Middle QA Manual →