Собеседование на Manual QA проверяет знание теории тестирования, техник тест-дизайна и умение писать баг-репорты, с которыми разработчик реально может работать. Ниже — вопросы, которые задают чаще всего на уровне Junior и Middle, каждый с эталонным ответом. Senior: архитектуру, трейд-оффы, менторство и принятие решений.
Дефект обычно проходит 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, а сообщения об ошибке не раскрывают, существует ли такой логин.
Тестирование показывает наличие дефектов, но не доказывает их отсутствие; исчерпывающее тестирование невозможно; раннее тестирование экономит время и деньги; дефекты скапливаются в небольшом числе модулей; парадокс пестицида — повторяющиеся тесты перестают находить новые баги; тестирование зависит от контекста; заблуждение об отсутствии ошибок — софт без известных дефектов всё равно бесполезен, если решает не ту задачу.
Таблица принятия решений сопоставляет комбинации входных условий с ожидаемыми действиями системы. Её применяют, когда поведение зависит от нескольких взаимодействующих условий — например скидка зависит от типа клиента, суммы заказа и промокода. Таблица делает пропущенные комбинации очевидными и напрямую превращается в тест-кейсы, поэтому это стандартная техника для сложной бизнес-логики.
Тест-кейс описывает точные шаги, тестовые данные и ожидаемый результат — его может повторить любой, и он подходит для регулируемой или сложной функциональности. Чек-лист — это список того, что нужно проверить, без предписанных шагов, с опорой на опыт тестировщика. Чек-листы быстрее писать и поддерживать, они хороши для исследовательской работы и стабильных областей; тест-кейсы нужны для онбординга, аудитов и фич, где важен точный сценарий.
Функциональное тестирование проверяет, что система делает — соответствует ли поведение фич требованиям. Нефункциональное проверяет, насколько хорошо она это делает: производительность, нагрузку, безопасность, удобство, доступность, совместимость и надёжность. Нефункциональные дефекты обычно дороже в исправлении, потому что чаще коренятся в архитектуре, а не в одной строке кода.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Senior QA Manual →