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