Собеседование на Manual QA проверяет знание теории тестирования, техник тест-дизайна и умение писать баг-репорты, с которыми разработчик реально может работать. Ниже — вопросы, которые задают чаще всего на уровне Junior и Middle, каждый с эталонным ответом. Junior: базовая теория, определения и простые практические кейсы.
Верификация отвечает на вопрос «правильно ли мы делаем продукт?» — проверяет работу на соответствие спецификациям и проектной документации, обычно через ревью и статический анализ. Валидация отвечает «тот ли продукт мы делаем?» — проверяет, что готовое ПО действительно решает задачу пользователя, через динамическое тестирование. Верификация идёт на протяжении всей разработки, валидация — против реальных требований и пользователей.
Эквивалентное разбиение делит входные данные на группы, где все значения ведут себя одинаково, поэтому достаточно проверить по одному значению из группы. Для поля возраста 1–120 классы такие: валидный 1–120, невалидный снизу (0 и отрицательные), невалидный сверху (121 и больше), невалидный тип (буквы, символы, пустое поле). Получается четыре теста вместо ста двадцати.
Анализ граничных значений проверяет края каждого класса, потому что именно там скапливаются ошибки на единицу. Для поля 1–100 проверяют 0, 1, 2 на нижней границе и 99, 100, 101 на верхней. Технику почти всегда применяют вместе с эквивалентным разбиением: классы показывают, какие группы есть, а границы — где они ломаются.
Severity описывает техническое влияние дефекта на систему, Priority — насколько срочно бизнес хочет его исправить. Их выставляют разные люди: Severity обычно тестировщик, Priority — продакт или менеджер. Падение в редко используемом админском экспорте — высокая Severity и низкий Priority; опечатка в названии компании на главной — низкая Severity и высокий Priority.
Дефект обычно проходит 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, а сообщения об ошибке не раскрывают, существует ли такой логин.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Junior QA Manual →