Собеседование на 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 →