Вопросы на собеседовании QA-инженера — часть 1/3: Junior с разбором ответов

Это часть 1 из 3. Часть 2: Middle → | Часть 3: Senior →

TL;DR: 8 вопросов, которые задают Junior QA на собеседованиях в 2024–2026 годах. Для каждого — разбор ответа, типичные ошибки и follow-up. Не пересказ учебника, а то, что реально спрашивают.

Как пользоваться: Открой перед собеседованием → пройдись по всем вопросам → проверь, можешь ли ответить на follow-up. Слабые места — в тренажёр.

Эта серия — не копия документации и не список из учебника Савина. Это вопросы, которые реально задают на собеседованиях QA-инженерам в 2024–2026 годах — по отзывам с Habr, Glassdoor и профильных сообществ. Для каждого вопроса: что интервьюер на самом деле проверяет, как ответить, и где большинство кандидатов ошибается.

В первой части — Junior-уровень: базовая теория, документация и практические задачи. Если ты только входишь в профессию или хочешь убедиться, что база на месте — это для тебя.

Содержание

Junior

• 1. Что такое тестирование и зачем оно нужно?
• 2. Чем отличается верификация от валидации?
• 3. Severity vs Priority — в чём разница?
• 4. Что должно быть в хорошем баг-репорте?
• 5. Тест-кейс vs чек-лист — когда что использовать?
• 6. Какие техники тест-дизайна вы знаете?
• 7. Что такое регрессионное тестирование?
• 8. Протестируйте форму логина за 5 минут до релиза

1. Что такое тестирование и зачем оно нужно?

Интервьюер проверяет: понимаешь ли ты суть профессии или просто заучил определение.

Как ответить:

Тестирование — это процесс проверки соответствия программного продукта заданным требованиям и ожиданиям пользователей. Но это не только поиск багов. Тестирование помогает оценить риски релиза, даёт команде уверенность в качестве продукта и снижает стоимость исправления дефектов — чем раньше нашёл баг, тем дешевле его починить.

Типичная ошибка: Отвечать «тестирование — это поиск багов». Это слишком узко. Интервьюер хочет услышать про бизнес-ценность: снижение рисков, защита пользователей, экономия денег на поддержке.

Follow-up: Чем отличается тестирование от QA? Тестирование — часть QA. QA (Quality Assurance) — это весь процесс обеспечения качества: от требований до мониторинга на продакшене. Тестирование — конкретная активность внутри этого процесса.

2. Чем отличается верификация от валидации?

Интервьюер проверяет: умеешь ли ты мыслить шире, чем «работает/не работает».

Как ответить:

• Верификация — проверяем, что продукт соответствует требованиям и спецификации. «Мы правильно делаем продукт?»
• Валидация — проверяем, что продукт решает реальную задачу пользователя. «Мы делаем правильный продукт?»

Пример: форма регистрации принимает email по спецификации (верификация прошла), но пользователи не могут зарегистрироваться с доменом .рф — продукт не решает их задачу (валидация провалена).

Типичная ошибка: Путать местами или говорить «это одно и то же, просто разные слова». Это принципиально разные концепции, и интервьюер хочет убедиться, что ты это понимаешь.

Follow-up: Приведите пример, когда верификация прошла, а валидация — нет.

3. Severity vs Priority — в чём разница?

Интервьюер проверяет: понимаешь ли ты, что не каждый критичный баг надо чинить первым.

Как ответить:

• Severity (серьёзность) — техническое влияние бага на систему. Насколько сильно он ломает функциональность.
• Priority (приоритет) — бизнес-срочность исправления. Определяется менеджером, а не тестировщиком.

Они не всегда совпадают:

• Высокий Priority, низкий Severity: Опечатка в названии компании на главной странице. Технически мелочь, но бизнес хочет починить немедленно.
• Высокий Severity, низкий Priority: Падение приложения при загрузке файла размером 10 ГБ. Серьёзный крэш, но 99% пользователей никогда не загружают такие файлы.

Типичная ошибка: Не суметь привести примеры пересечений. Заученное определение без примеров — красный флаг для интервьюера.

Follow-up: Кто устанавливает Priority? Может ли тестировщик его изменить?

4. Что должно быть в хорошем баг-репорте?

Интервьюер проверяет: умеешь ли ты коммуницировать дефекты так, чтобы разработчик мог их воспроизвести.

Как ответить:

Обязательные атрибуты:

• Заголовок — по формуле «Что? Где? Когда?». Пример: «Кнопка 'Оплатить' не реагирует на клик на странице корзины после добавления 10+ товаров»
• Окружение — ОС, браузер, версия приложения, сервер (stage/prod)
• Шаги воспроизведения — пронумерованные, конкретные, без лишних действий
• Ожидаемый результат — что должно происходить по требованиям
• Фактический результат — что происходит на самом деле
• Severity и Priority
• Вложения — скриншоты, видео, логи

Типичная ошибка: Писать «Кнопка не работает» без шагов воспроизведения. Или давать 15 шагов, когда достаточно 3-х — разработчик не будет это читать.

Follow-up: Как написать баг-репорт, если баг воспроизводится не каждый раз?

Мы разобрали фундамент — определения и документацию. Дальше — вопросы про методологию тестирования. Сложность чуть растёт.

5. Тест-кейс vs чек-лист — когда что использовать?

Интервьюер проверяет: понимаешь ли ты, что документация — не ради документации, а ради эффективности.

Как ответить:

• Тест-кейс — детальное пошаговое описание проверки с предусловиями, шагами и ожидаемым результатом. Используй, когда: критичная бизнес-логика, нужна передача другому тестировщику, требуется аудит.
• Чек-лист — краткий список проверок без детализации шагов. Используй, когда: опытный тестировщик, быстрый smoke-тест, исследовательское тестирование.

На практике чек-листы используют чаще — они быстрее в создании и поддержке. Тест-кейсы нужны для критичных сценариев и регрессии.

Типичная ошибка: Говорить «тест-кейсы лучше, потому что подробнее». Нет — они дороже в поддержке. Хороший тестировщик выбирает инструмент под задачу.

Follow-up: На проекте 200 тест-кейсов, но продукт быстро меняется. Что делать?

6. Какие техники тест-дизайна вы знаете?

Интервьюер проверяет: умеешь ли ты системно подходить к созданию тестов, а не тестировать «наугад».

Как ответить:

Основные техники:

• Классы эквивалентности — разделяем входные данные на группы, в которых поведение системы одинаково. Из каждого класса берём одно значение.
• Граничные значения — проверяем значения на границах классов: минимум, максимум, min-1, max+1.
• Таблица решений — для комбинаций условий: строим таблицу всех возможных комбинаций и ожидаемых результатов.
• Попарное тестирование (Pairwise) — сокращаем количество комбинаций, покрывая все пары параметров.

Пример для поля «Возраст» (допустимо 18–65):

• Классы: <18, 18–65, >65
• Граничные: 17, 18, 19, 64, 65, 66

Типичная ошибка: Перечислить названия без понимания, как применять. Интервьюер почти наверняка попросит пример — готовь его заранее.

Follow-up: Примените граничные значения для поля ввода промокода длиной от 4 до 12 символов.

7. Что такое регрессионное тестирование?

Интервьюер проверяет: понимаешь ли ты, зачем перетестировать то, что уже работало.

Как ответить:

Регрессионное тестирование — проверка того, что новые изменения в коде не сломали существующую функциональность. Проводится после каждого релиза, багфикса или рефакторинга.

Отличие от ретеста: ретест — проверяешь, что конкретный баг исправлен. Регрессия — проверяешь, что исправление не сломало что-то другое.

В реальных проектах полная регрессия занимает слишком много времени, поэтому выбирают приоритетные сценарии на основе:

• Изменённых модулей и их зависимостей
• Критичности функциональности для бизнеса
• Исторических данных о нестабильных участках

Типичная ошибка: Путать регрессию с ретестом. Или говорить «прогоняем все тесты заново» — интервьюер хочет услышать про приоритизацию.

Follow-up: Как выбрать тесты для регрессионного набора при ограниченном времени?

8. Протестируйте форму логина за 5 минут до релиза

Интервьюер проверяет: умеешь ли ты приоритизировать в условиях ограничений, а не пытаться покрыть всё.

Как ответить:

За 5 минут — только критический путь:

1. Позитивный сценарий — ввести валидный логин и пароль, нажать «Войти». Убедиться, что пользователь залогинен.
2. Пустые поля — отправить форму без данных. Должна быть валидация.
3. Неверный пароль — ввести правильный логин, неправильный пароль. Убедиться в корректном сообщении об ошибке (без подсказок «пароль неверный» — это проблема безопасности).
4. SQL-инъекция — ввести ' OR 1=1 -- в поле логина. Форма не должна пропустить.

Если осталось время: 5. Проверить, что пароль маскируется 6. Проверить кнопку «Показать пароль» 7. Проверить работу по Enter

Типичная ошибка: Начинать с негативных сценариев или тестировать вёрстку. В условиях ограничений — сначала happy path, потом безопасность, потом всё остальное.

Follow-up: А если форма с капчей и двухфакторной аутентификацией — как изменится приоритет?

Итого Junior: 8 вопросов. Фокус — теория тестирования, документация, тест-дизайн и умение приоритизировать. Если уверенно отвечаешь на follow-up — ты готов к собеседованию на Junior QA.

Как готовиться

• Теория: Роман Савин «Тестирование dot com», ISTQB Foundation Level Syllabus — для системной базы
• Практика: Тестируй всё вокруг — формы на сайтах, мобильные приложения, бытовые предметы. Записывай баг-репорты
• Техники тест-дизайна: Решай задачи на граничные значения и классы эквивалентности — это спрашивают почти везде
• Время на подготовку: 1–2 недели при ежедневных занятиях по 1–2 часа

Чего НЕ спрашивают

• Водопадная модель в деталях — в 2026 году это уже история, а не рабочий процесс
• UML-диаграммы — от джунов не ждут знания нотаций
• Знание конкретных инструментов (Jira, TestRail) — это учится за день на рабочем месте, интервьюерам важнее мышление

Как попробовать Sobes AI

Sobes AI — это AI-ассистент, который помогает на технических собеседованиях в реальном времени.

1. Зайди на sobesai.app и скачай приложение
2. Запусти перед собеседованием или тренировкой
3. AI слушает вопросы и подсказывает структурированные ответы
4. Отрабатывай вопросы из этой статьи с мгновенной обратной связью

Это часть 1 из 3. Часть 2: Middle → | Часть 3: Senior →