Собеседование начинающего QA: вопросы, задачи и инструменты

На техническом интервью новичок может уверенно пересказать разницу между верификацией и валидацией, а через минуту задуматься над просьбой: "Перед вами форма заказа. Как будете её проверять?"

Определения помогают в разговоре, но важно также показать, умеете ли вы задавать вопросы до начала тестов, отличать подтверждённое требование от догадки и объяснять, зачем нужна каждая проверка. Название техники тест-дизайна не заменяет понимания того, что должна делать программа.

Разберём базовые темы для подготовки к собеседованию junior QA: термины, практические задачи, баг-репорт, инструменты и работу с ИИ.

Иллюстрация подготовки к собеседованию тестировщика.

Вопросы junior QA: логика терминов вместо заучивания

Точный список вопросов заранее неизвестен, а привычные термины в командах могут трактовать по-разному. Поэтому полезно понимать смысл понятий и уметь приводить короткие примеры.

QA, QC и роль тестировщика

• QA (Quality Assurance, обеспечение качества) охватывает процессы на всём жизненном цикле продукта: от уточнения требований до анализа причин, по которым ошибки попадают к пользователям.
• QC (Quality Control, контроль качества) сосредоточен на проверке результата: поиске дефектов в сборке и сравнении поведения программы с требованиями.
• Тестировщик проверяет продукт и сообщает о найденных проблемах. Даже начинающий специалист помогает качеству процесса, если заранее замечает противоречие в задаче и обсуждает его с командой.

Пример ответа: "Контроль качества помогает найти ошибку в готовой форме оплаты, а обеспечение качества помогает заранее уточнить, какие способы оплаты должны поддерживаться".

Чек-лист и тест-кейс

Чек-лист представляет собой компактный список того, что нужно проверить. Например: добавление товара в корзину, изменение количества и удаление позиции.

Тест-кейс описывает конкретный сценарий подробнее: предусловия, шаги, данные и ожидаемый результат. Его удобно использовать, когда проверку должны воспроизводить разные люди или когда важны точные условия.

В команде могут использовать оба формата: например, краткий чек-лист для исследовательской проверки и подробный тест-кейс для критичного сценария оплаты.

Уровни и типы проверок

Уровень помогает понять, какую часть системы мы проверяем:

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

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

Severity и Priority

Severity, или серьёзность, описывает влияние дефекта на систему или пользователя. Priority, или приоритет, помогает определить очередность исправления.

Например, опечатка в названии компании на главном экране перед рекламной кампанией может иметь низкую серьёзность, но высокий приоритет. И наоборот: серьёзный сбой редко используемого административного отчёта не всегда исправляют первым. Конкретную оценку команда принимает с учётом последствий и сроков.

Smoke и регрессия

Smoke-тестирование проверяет основные функции после новой сборки: например, открывается ли сайт, можно ли войти и создать заказ.

Регрессионное тестирование помогает выяснить, не нарушили ли изменения ранее работавшее поведение. Его объём зависит от изменений, рисков и времени на проверку; он не обязан всегда быть шире конкретного smoke-набора.

Задачи тестировщика: тест-дизайн на примерах

На практической части интервью могут дать короткое условие и попросить составить проверки. Важно не угадать "идеальный ответ", а показать ход мыслей: выделить группы значений, проверить границы и обозначить пробелы в условии.

Задача 1. Поле "Возраст"

Допустим, по учебному условию поле принимает целый возраст от 18 до 65 лет включительно. Значения 17 и 66 должны отклоняться, а 18 и 65 приниматься.

• Значение внутри диапазона: 30 принято.
• Нижняя граница: 18 принято.
• Ниже нижней границы: 17 отклонено.
• Верхняя граница: 65 принято.
• Выше верхней границы: 66 отклонено.
• Дробное число: 25,5 отклонено, условие допускает только целые числа.

Также стоит обсудить:

• Пустое поле: обязательно ли его заполнять?
• Текст и символы: можно ли ввести буквы и что произойдёт при отправке?
• Пробелы: значение 18 нужно очистить от пробелов или отклонить?
• Сообщение об ошибке: когда и каким образом пользователь узнает о проблеме?
• Ведущие нули: допустимо ли значение 018?

Условие пока не даёт ответы на все эти вопросы. Не стоит придумывать требования: лучше обозначить варианты и уточнить ожидаемое поведение у команды.

Задача 2. Корзина интернет-магазина

Пусть пользователь может менять количество товара, видеть пересчёт итоговой суммы и удалять позицию.

Из учебного условия следует, что при изменении количества итоговая сумма пересчитывается, а позицию можно удалить. Стоит проверить количество 1 и 2, корректный пересчёт и удаление последнего товара.

Что ещё нужно уточнить:

• Что произойдёт, если на складе осталось три товара, а пользователь ввёл пять?
• Удаляет ли значение 0 товар из корзины?
• Как рассчитываются скидка и округление?
• Что увидит пользователь, если сервер вернул ошибку?
• Что произойдёт, если открыть корзину в двух вкладках и изменить её в одной из них?
• Как выглядит пустая корзина и доступно ли из неё оформление заказа?

Отдельная ловушка: ответ HTTP 200 в сетевой вкладке браузера сам по себе не доказывает, что данные записались в базу. Для дополнительной проверки можно обновить страницу или повторно запросить данные через API. Но ответ может прийти из кеша, поэтому подтверждение записи именно в базу потребует надёжного источника, например чтения соответствующей таблицы, если доступ разрешён.

Если в вашей вакансии указана работа с базами данных, можно дополнительно разобрать вопросы и задачи по SQL.

Баг-репорт: учебный пример

Хороший баг-репорт помогает коллеге воспроизвести проблему и понять, с каким требованием расходится результат.

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

• Заголовок: итоговая сумма корзины не пересчитывается при уменьшении количества.
• Окружение: Chrome, Windows 11, учебный тестовый стенд.
• Предусловия: пользователь авторизован; в корзине две термокружки по 1000 условных единиц; итог составляет 2000.
• Шаги:
  1. Открыть корзину.
  2. Уменьшить количество термокружек с двух до одной.
  3. Дождаться завершения запроса на обновление корзины.
• Фактический результат: количество изменилось на одно, стоимость строки стала 1000, но итог остался 2000 до перезагрузки страницы.
• Ожидаемый результат: итог автоматически обновляется до 1000.

В отчёте нет догадки о причине ошибки в коде. Есть условие, шаги и наблюдаемое расхождение.

Инструменты QA: что они показывают

Начинающему тестировщику не нужно знать десятки программ до первого оффера. Список зависит от вакансии; важнее понимать назначение инструмента и честно говорить о своём опыте.

• DevTools в браузере. Вкладка Network показывает запросы и ответы, Console помогает заметить ошибки JavaScript. Можно объяснить, как вы проверяли отправку учебной формы и смотрели ответ сервера.
• Postman или аналог. Позволяет отправлять запросы к API без работы через интерфейс и проверять метод, заголовки, тело и ответ.
• Jira, YouTrack или другой трекер. Помогает вести задачи и дефекты, отслеживать статусы и обсуждения. Даже если вы пользовались только учебной доской, полезно объяснить, какие сведения нужны в карточке ошибки.
• TestRail или аналог. Помогает хранить тест-кейсы, объединять их в прогоны и фиксировать результаты. Ту же базовую логику можно освоить и в таблице.
• SQL-клиент. Нужен для работы с данными базы, если это предусмотрено ролью и доступом. На собеседовании лучше честно назвать освоенные команды и объяснить, зачем нужен запрос.
• Playwright. По официальной документации, это инструмент для сквозных проверок веб-приложений в Chromium, Firefox и WebKit; проверки можно запускать локально и в CI. Не обязательно приписывать себе промышленную автоматизацию: можно объяснить, какие стабильные сценарии вы бы рассмотрели для автотестов.

ИИ в тестировании: помощь и проверка результата

ИИ можно применять не только при подготовке к собеседованию, но и в работе тестировщика. Например, попросить модель:

• предложить дополнительные проверки;
• составить черновик тест-кейса или баг-репорта;
• выделить вопросы к аналитику из длинного требования;
• подготовить набросок кода для автопроверки.

При этом модель может придумать несуществующее поле, перепутать границы или предложить неверное ожидаемое поведение. Ответ нужно сверять с требованиями, а код автотеста нужно запускать и проверять в разрешённой среде.

В закрытых корпоративных контурах используют локально развёрнутые модели, в том числе китайские и адаптированные под задачи компании. Например, документация Qwen описывает развёртывание Qwen3 как локального сервиса через vLLM. Выбор модели, изоляции и необходимости дообучения зависит от организации.

Передавать реальные требования, логи, код или данные клиентов в модель нужно только в рамках разрешений и правил компании. Локальное размещение само по себе не доказывает защищённость всей инфраструктуры.

Пример: как проверить идею модели

Представим, что тестировщик дал модели учебное условие: "Поле принимает целый возраст от 18 до 65 включительно. Предложи проверки границ и невалидного ввода".

Модель может предложить:

1. 18: принять.
2. 65: принять.
3. 17: отклонить.
4. 66: отклонить.
5. 30,5: отклонить.
6. 0: принять как значение по умолчанию.

Первые пять пунктов соответствуют условию. Шестой не соответствует условию: 0 меньше 18 и должен отклоняться. Кроме того, в списке нет вопроса о пустом поле. Такой черновик помогает собрать идеи, но специалисту всё равно нужно сверить их с условиями задачи.

Проактивность: как предложить улучшение

От начинающих специалистов всё чаще ждут не только прохождения готовых инструкций, но и инициативы. Это не означает, что каждый junior обязан самостоятельно перестроить процесс: важно замечать повторяющиеся проблемы и предлагать разумные улучшения.

Допустим, команда перед каждым релизом вручную повторяет одни и те же проверки корзины. Можно:

1. Выделить стабильные сценарии и те, что часто меняются.
2. Оценить, какие проверки разумно автоматизировать, а какие проще оставить ручными.
3. Предложить команде небольшой эксперимент на тестовом стенде.
4. Согласовать изменения и не менять рабочую среду без разрешения.
5. Проверить результат: экономят ли скрипты время и не дают ли много ложных срабатываний.

Цель состоит не в том, чтобы написать как можно больше скриптов, а в том, чтобы сделать работу команды надёжнее и удобнее.

Самопроверка перед собеседованием

Попробуйте ответить вслух без конспекта:

1. Вам сказали: "Форма скидки работает от суммы 3000 рублей". Какие вопросы вы зададите до начала проверки?
2. Чем отличаются Severity и Priority на примере дефекта этой формы?
3. Что вы посмотрите в DevTools, если нажали "Применить скидку", а сумма не изменилась?
4. Как описать шаги так, чтобы коллега смог воспроизвести проблему?

Interview Ninja можно использовать не только во время собеседования, но и при подготовке, на рабочих митингах и созвонах: например, для консультации по теме QA, объяснения незнакомого понятия или формулирования вопросов команде. После разговора полезно разобрать доступную сохранённую историю или собственные заметки; подробнее о работе с историей читайте в описании функции.

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

Если хотите получать новые разборы вопросов и задач для технических интервью, можно заглянуть в Telegram-канал Interview Ninja.

На первом собеседовании тестировщика не бойтесь сказать: "Я уточню это в документации" или "Ответ зависит от требований". Спокойная логика, внимание к деталям и честный рассказ о своём опыте полезнее заученного списка терминов.